Como oferecer um teste gratuito para o seu dApp

Existem vários tópicos que solicitam expressões de visível dor quando levantados em conversas com desenvolvedores de aplicativos descentralizados. O chefe entre estes tópicos são:

  1. Manuseio da chave da conta. Os desenvolvedores não podem pedir aos usuários suas frases chaves privadas / frases sementes, mas o usuário sempre tem que assinar transações.
  2. A necessidade de pagar taxas para cada transação. Como você explica aos usuários que cada transação exige uma tarifa a ser paga no token nativo da plataforma? Mais importante, onde os usuários irão obter os tokens para as suas primeiras transações?

Estes problemas levam a um custo muito elevado de captação por usuário. Por exemplo, um dos mais populares dApps no ecossistema waves tiveram um custo de captação de clientes de cerca de US$ 80 – com valor vitalício (LTV) de menos de US$ 10! O processo de conversão foi estragado pelas barreiras envolvidas nos dois problemas descritos acima.

O primeiro problema é muitas vezes resolvido com extensões do navegador como MetaMask e Waves Keeper. No entanto, esta solução não é particularmente fácil de usar e requer muito esforço, levando ao desenvolvimento do Signer para o ecossistema Waves. O Signer não força a instalação de extensões do navegador. Este artigo por Vladimir Zhuravlev discute isso, e como integrar Waves Signer em sua aplicação.

E quanto ao segundo problema? Muitos criadores dApp não se preocupam com esta questão, embora, é claro, os usuários têm de encontrar tokens para a tarifa em algum lugar. Outros exigem que os usuários paguem com cartões de plástico durante o registro/autorização, o que reduz as taxas de conversão.

Vou mostrar-lhe como resolver o problema de tarifas e como fazer um dApp que não exige ao usuário a adquirir os tokens nativos. Ele permite que você ofereça períodos experimentais para o dApp ou interações iniciais gratuitas. Há duas maneiras de fazer isto com Waves. Nós vamos tratar de ambas.

Transações patrocinados

Se o seu dApp inclui o uso de um token interno, que todos os usuários precisam acessar sua funcionalidade, então você pode usar o mecanismo de transação patrocinada. Os usuários vão pagar as tarifas em seu token, mas desde que os mineiros recebem recompensas em WAVES apenas, as WAVES  serão debitados da conta que emitiu o token e configurar configurou o patrocínio. Vamos rever essas etapas porque este é um ponto importante para entender:

  • O usuário paga uma tarifa de transação em seu token personalizado
  • Você, como o emissor do token, recebe esses tokens
  • Os tokens WAVES são deduzidos da sua conta na quantidade necessária e são pagas aos mineiros

A pergunta que provavelmente surgirá de imediato é, quantos tokens serão o usuário irá pagar, e quantas WAVES serão debitados da conta do patrocinador?

Resposta: o emissor do ativo define essa relação ele mesmo. Na hora do patrocínio, o criador do token decide quantos de seus tokens irão corresponder à tarifa mínima (0,001 Waves ou 100.000 Wavelets, visto que o código, obriga-nos a lidar com a unidade mínima). Vamos olhar alguns exemplos e códigos para fazer as coisas mais claras.

Para ativar o patrocínio, você deve enviar uma transação sponsorship. Você pode fazer isso usando a interface do usuário na Waves.Exchange ou você pode fazê-lo manualmente ou com código usando waves-transaction. O código pode parecer da seguinte forma:

O parâmetro mais importante na transação é minSponsoredAssetFee, Que define a equivalência de 100 A tokens para 0,001 WAVES. Assim, a fim de fazer uma  trasnferTransaction, o usuário terá de anexar 100 A tokens como tarifa.

É importante perceber algumas das limitações de patrocínio. Tokens Patrocinados só pode ser usado como as tarifas de tipos de transação Transfer e InvokeScript. Apenas a conta que emitiu  o token pode patrociná-lo. Você não será capaz de patrocinar tokens emitidos por outras contas.

Notas de segurança

Antes de ativar o patrocínio, você deve compreender os seguintes pontos importantes:

  1. O usuário pode pagar com fichas patrocinadas para transações que não envolvem esse token. Por exemplo, uma conta com tokens A e B no seu balanço pode enviar tokens B e anexar o token A como tarifa.
  2. O usuário não pode pagar apenas a tarifa mínima de transação. Por exemplo, se um usuário tem 100.000 de seus tokens, e você definir o parâmetro minSponsoredAssetFee para 100, O usuário, no entanto, será capaz de pagar toda a seus 100.000 tokens como tarifa para uma única transação. Você receberá 100.000 tokens A, e o mineiro receberá 1.000 WAVES da sua conta (100.000 / 100 = 1.000).

Tarifas devidas pelo dApp

AVISO LEGAL: Esta função não está documentada e pode parar de funcionar no futuro. EU NÃO recomendo usar este método, mas é bom saber.

A segunda opção só funciona para transações InvokeScript e é bastante simples. A vantagem sobre patrocínio de tokens é que você não precisa usar um token interno para o seu dApp.

Qualquer usuário pode chamar o dApp com 0 WAVES em sua conta. A transação terá êxito se o dApp transferir tokens WAVES para o usuário como resultado da chamada. Isto é mais fácil de entender com um exemplo.

Vamos dizer que há um dApp que envia ou não envia 1 WAVES para quem invoca a chamada, com base em seu endereço. (Este exemplo é completamente inseguro e é fornecido apenas para fins explicativos. Nunca use essa lógica em suas aplicações descentralizadas!)

Se você chamar essa função de uma conta com 0 WAVES no balanço, especificando a tarifa de 0,005 Waves, o script será executado. Se a condição takeRight (invoke.caller.bytes, 4) == base16’ABCD’ retornar TRUE, então a transação será considerada válida e vai para o blockchain. O usuário receberá primeiro 1 WAVES como resultado da chamada e, em seguida, a tarifa de 0,005 será deduzida do seu balanço.

Como resultado, o usuário terá 0,995 WAVES em sua conta.

Leitores atentos já terão reconhecido que o script acima não é seguro porque você pode chamá-lo tantas vezes quanto você quiser – se a conta não “ganhar” 1 WAVES, Então a transação não irá para o blockchain e nenhuma tarifa será incorrida. Se a conta “ganhar”, ele receberá 0,995 WAVES. É efetivamente uma loteria com bilhetes gratuitos.

A abordagem correta é incluir condições adicionais para verificar se o usuário tem o direito de chamar o script para gratuíto ou não – por exemplo, para usar uma lista de permissões.

Eu também gostaria de observar que, se no futuro, o modelo de execução do contrato em WAVES mudar e transações com exceções (throw()) serão também gravados no blockchain, então o uso dessa funcionalidade será impossível.

A discussão de como a funcionalidade descrita acima funciona, e possíveis caminhos de desenvolvimento, pode ser encontrado nesta questão no GitHub.

Melhores Práticas

Eu recomendo que ambas as soluções são utilizadas apenas para os ensaios de produtos de modo temporário. Como um desenvolvedor, você sempre tem que verificar todas as condições de contorno, pois o uso inadequado pode levar à perda de fundos.