Como um mecanismo de jogo para DeFi poderia facilitar o desenvolvimento acelerado

O coração pulsante de qualquer ecossistema de aplicativos descentralizados, DApps, é sua pilha de tecnologia subjacente. Para o Ethereum (ETH), este é o consenso “Nakamoto”, o ambiente de execução da Ethereum Virtual Machine (EVM) e a linguagem de programação Solidity. Juntas, essas tecnologias permitiram que os desenvolvedores de contratos inteligentes impulsionassem as finanças descentralizadas (DeFi) do conceito à realidade.

Para que o DeFi dê o próximo salto – para a adoção generalizada – a escalabilidade é o requisito tecnológico que mais chama a atenção. Mas um aspecto muitas vezes esquecido, mas igualmente importante, das plataformas de camada um é sua abordagem ao desenvolvimento de contratos inteligentes. 

Enquanto Solidity e EVM são as principais tecnologias que permitiram que o Ethereum fosse inquestionavelmente o pioneiro do DeFi, os pioneiros também são aqueles que cometem todos os erros. Você já se perguntou por que parece que há uma série interminável de hacks e exploits DeFi hoje? É o resultado de uma abordagem de programação que torna incrivelmente difícil gerenciar tokens com segurança. Porque quando o Ethereum estava sendo projetado, o DeFi não existia.

Mas uma correção não é fácil. Grandes alterações no Solidity e no EVM não são possíveis, pois isso quebraria a maioria dos DApps que já foram construídos. Portanto, as plataformas mais novas têm uma oportunidade real de aprender e aprimorar a experiência do desenvolvedor – porque os DApps aprimorados que esses desenvolvedores criam podem permitir a próxima onda de adoção do DeFi.

Por que o desenvolvimento de DeFi é difícil para o Ethereum

Sejam tokens para empréstimos e empréstimos descentralizados, tokens para um jogo NFT ou peça de arte ou tokens para um derivativo financeiro, eles estão no centro de praticamente todos os casos de uso em DeFi e criptografia. 

No entanto, o único token que a plataforma Ethereum entende nativamente é o ETH. Todos os outros tokens, seja sob o ERC-20, 721, 1155 ou qualquer outro padrão, existem apenas como variáveis ​​(números antigos regulares) dentro de cada contrato inteligente.

O token Tether – USDT –– é uma lista de contas e saldos associados dentro do contrato inteligente USDT. O mesmo vale para Shiba Inu (SHIB) e todos os outros tokens construídos no Ethereum. É por isso que você não pode trocar ETH no Uniswap (UNI) e, em vez disso, você precisa, bizarramente, trocar o ETH encapsulado (wETH), que é um token ERC-20 apoiado pelo ETH mantido sob custódia.

Isso traz problemas. Você não pode “enviar” tokens de uma pessoa para outra porque os tokens não ficam na carteira do usuário. Eles vivem apenas como um saldo associado a uma conta dentro de cada contrato individual.

Para trocar USDT por SHIB, é enviada uma mensagem para debitar sua conta no contrato USDT e creditar sua conta no contrato SHIB. Mas o USDT debitado de sua conta deve ir para alguma outra conta no contrato USDT e, da mesma forma, o SHIB creditado em sua conta deve ter vindo de alguma outra conta no contrato SHIB.

Com o ônus de implementar um novo token em cada contrato inteligente e para os desenvolvedores garantirem que seus contratos sejam seguros em todos os cenários possíveis, os desenvolvedores gastam quase todo o tempo, até 90%, em testes e validação. Isso deixa pouco tempo para eles construirem o que realmente querem: a funcionalidade DeFi.

Com uma experiência de desenvolvedor tão frustrante, existe uma maneira melhor? 

Tokens como o núcleo do desenvolvimento DeFi

DeFi é tudo sobre tokens. Isso significa que os tokens não devem ser uma reflexão tardia na experiência de desenvolvimento – eles devem estar na frente e no centro – bem no centro da plataforma.

É por isso que a linguagem de programação certa pode acelerar o desenvolvimento não apenas de uma única plataforma, mas de toda uma indústria. Um exemplo disso é o Radix, um protocolo de camada um, que usa programação “orientada a ativos” e o está introduzindo com sua linguagem de programação Scrypto.

Como funciona? Primeiro, os tokens não são mais definidos dentro de um contrato inteligente, como na lista de contas e saldos descritos acima. Em vez disso, os tokens ficam em uma camada separada, seguindo as regras que a plataforma impõe. Assim como a plataforma Bitcoin impõe que o BTC não pode ser gasto duas vezes, drenado ou perdido em uma transação, a programação orientada a ativos também garante esses mesmos tipos de comportamentos lógicos, mas para cada token criado na plataforma. 

Com essas regras em vigor, os tokens ganham as mesmas propriedades que você esperaria de uma moeda física no seu bolso. Você pode entregá-lo fisicamente a outra pessoa, mas a plataforma garante que é impossível que o token esteja em dois lugares ao mesmo tempo, nem pode desaparecer. 

Dada essa fisicalidade do comportamento, os desenvolvedores de DeFi podem criar DApps de DeFi como eles os desenhariam intuitivamente em um quadro branco. Palavras como “pegar” e “colocar” na linguagem de programação realmente pegam e colocam tokens em lugares.

Chega de definir as regras de finanças em cada contrato inteligente, do zero, como no Solidity. Com o Radix, os desenvolvedores recebem todas as ferramentas necessárias para criar código seguro rapidamente – aumentando sua produtividade.

Em última análise, se os desenvolvedores migram para um novo paradigma ou preferem o antigo depende de um equilíbrio refinado entre o efeito de rede do antigo versus as vantagens do novo.

Aprender uma nova abordagem para desenvolver DeFi dá trabalho. E isso é especialmente arriscado se o ecossistema para o qual você está construindo estiver começando do zero, em comparação com um com milhares de DApps, comunidades de desenvolvedores maduras e milhões de usuários. 

Mas, como vimos em 2021, novas camadas podem crescer rapidamente. Com a execução correta, há uma chance de vermos um novo arrivista na cidade. Um que pode muito bem ser capaz de galvanizar uma comunidade de desenvolvedores focados na adoção convencional do DeFi.