Info+News+Tech

Web3 é um novo mundo doméstico em desenvolvimento para a Internet descentralizada. É um playground, com uma infraestrutura não tão forte como o seu antecessor Web2.

A experiência do desenvolvedor para Web3 é repleta de inconveniências, incluindo inchaço, falta de padronização de protocolo, suporte limitado para outras plataformas e muito mais.

Esses problemas não são realmente vocalizados além da comunidade de desenvolvedores Web3. Para trazer alguns desses problemas à tona, vamos mergulhar em alguns dos mais comuns para os construtores Web3.

1- Canal de integração lento de dApp
A integração da Web3 em aplicativos hoje é extremamente lenta, especialmente quando comparada à Web2.

Na Web2, a lógica complexa do aplicativo é transferida para servidores centralizados. Por exemplo: quando um usuário tweeta, o aplicativo simplesmente faz uma solicitação à API do Twitter, que posta um tweet em nome do usuário. Isso permite que os aplicativos permaneçam leves e integrem dezenas de APIs perfeitamente.

Mas na Web3, os aplicativos lidam com essa lógica complexa, porque os servidores centrais foram substituídos por redes P2P e caros contratos inteligentes.

Para integrar protocolos Web3 em aplicativos rapidamente, os desenvolvedores de protocolo mantêm SDKs do lado do cliente para os desenvolvedores de aplicativos usarem. Esse processo requer muito tempo e energia, tanto do desenvolvedor do protocolo quanto do desenvolvedor do aplicativo.

Para entender por que esses SDKs do lado do cliente são necessários e por que demoram para serem desenvolvidos, devemos primeiro mergulhar na gama de recursos que um aplicativo Web3 típico pode querer incluir.

Ao construir um dApp (aplicativo descentralizado), muitas vezes você não está apenas interagindo com contratos inteligentes. Os aplicativos Web3 geralmente implementam uma variedade de recursos, como: mensagens ponto a ponto, armazenamento descentralizado, produção de assinaturas e provas criptográficas, interação com cadeias laterais e a lista continua.

Como podemos ver, construir um aplicativo habilitado para Web3 não é tão simples quanto interagir com um único endpoint em um servidor.

Alguns exemplos de SDKs Web3 são: libp2p , DAI.js , Ether.js , Aragon.js . Ao fazer as coisas dessa maneira, todas as alterações no back-end devem ser integradas manualmente até o front-end.

Isso pode incluir a republicação de um pacote que contém todos os seus endereços onchain, a modificação e publicação da nova versão do SDK Javascript e, por último, a integração desses novos pacotes em seu aplicativo ao publicá-lo também.

Esse ciclo de desenvolvimento é muito diferente daquele ao qual os desenvolvedores da web2 estão acostumados. Normalmente, eles são capazes de fazer alterações no back-end e refleti-las automaticamente no front-end, se a API do serviço permanecer consistente.

2- Web3 não é multiplataforma
A Web3 possibilitou uma infinidade de inovações incríveis por meio de aplicativos Javascript baseados em navegador. No entanto, o mundo do software é muito maior do que o navegador.

Considere outros tipos de aplicativos, como: móvel, servidor, videogames e IoT. Em todos esses casos de uso, Javascript normalmente não é o idioma de escolha. Isso se deve principalmente ao fato de que o interpretador JS é muito pesado e complexo de integrar.

Para levar o Web3 a esses vários ambientes, os desenvolvedores já estão criando e mantendo vários SDKs. Por exemplo, você pode encontrar um SDK IPFS em JS , Python , Go , Rust e Objective-C .

Existem custos significativos para criar e manter essas bibliotecas, tornando preventivamente difícil dimensionar integrações de protocolo.

Imagine ter uma estante de centenas de livros em ordem alfabética, e cada novo livro adicionado significa que você deve alinhar cada um dos livros em ordem alfabética, tudo de novo.

Esta é a dor de cabeça do desenvolvedor web3. Cada novo protocolo Web3 que é desenvolvido tem sua própria “estante de livros”, que apenas aumenta o tempo necessário para manter e aumentar o ecossistema de desenvolvimento Web3.

3- Os protocolos são extensíveis, enquanto os dApps não são
Então, como está o ecossistema hoje? Bem, hoje podemos publicar extensões para protocolos. Alguns grandes exemplos disso são Aragon e Yearn .

Para Yearn, você pode publicar novas estratégias e adicioná-las aos cofres mediante consenso.

A desvantagem é que o aplicativo não é atualizado dinamicamente com detalhes sobre como a estratégia está funcionando. Em um cenário ideal, o aplicativo Yearn Vault permitiria a qualquer usuário clicar em uma estratégia, inspecionar sua mecânica e interagir com as alavancas e polias expostas que a mantêm funcionando. Em vez disso, isso está sendo feito nos bastidores por um pequeno grupo de mantenedores e entusiastas.

No caso do Aragon, os desenvolvedores podem publicar novas partes do protocolo on-chain, mas o mesmo cenário se repete onde o aplicativo do lado do cliente não é atualizado dinamicamente para suportar a nova funcionalidade on-chain.

Por exemplo, se um desenvolvedor criou um novo contrato de votação quadrática e o publicou on-line, seria ótimo se o aplicativo Aragon fosse capaz de exibi-lo e usá-lo automaticamente (contanto que adere a uma interface padrão).

A principal razão pela qual isso não é possível tem a ver com a insegurança do Javascript. Para que o aplicativo execute a lógica descrita acima, você precisa injetar dinamicamente um novo código dentro do aplicativo. Isso é extremamente inseguro no mundo do Javascript. Mais detalhes sobre isso aqui .

No entanto, existem maneiras de contornar isso, aproveitando algo como WebAssembly, onde é muito fácil criar uma nova instância de VM segura. Isso permite a injeção segura de código, que ativa o comportamento dinâmico do lado do cliente.

4- Custos de composibilidade
Quais são os custos associados à composição do Web3? Para entender isso, devemos lembrar o fato de que a integração de protocolos Web3 requer SDKs do lado do cliente.

A cada novo SDK adicionado, o tamanho do aplicativo aumenta. Além de inchar o aplicativo, os SDKs costumam ter dependências conflitantes, levando a incompatibilidades e muitas dores de cabeça.

Isso significa que há de fato um limite superior de quantas integrações um aplicativo pode ter. Isso é muito diferente do paradigma de microsserviço da Web2, em que cada API imaginável está a uma solicitação HTTP de uma linha.

No Web3, tudo deve ser transparente, compatível e reutilizável. Essa é a beleza e o espírito do código aberto. Se aplicarmos esse pensamento aqui, gostaríamos de imaginar um futuro em que o aplicativo Web3 médio use dezenas de integrações, mas isso parece improvável se continuarmos no caminho dos SDKs do lado do cliente.

5- Dependências inseguras de Javascript
Javascript é conhecido por ser inseguro. Por exemplo, uma dependência inválida pode substituir algum código de outras dependências e injetar uma lógica nefasta que pode roubar todos os fundos do usuário.

Muitos projetos foram criados pela comunidade Web3 para tentar consertar isso (como o LavaMoat ), mas esses são simplesmente curativos para um problema muito maior.

As inseguranças do Javascript não só colocam em risco os fundos do usuário, mas também atrapalham a inovação no espaço. Conforme mencionado acima na seção 3, os desenvolvedores de aplicativos são incapazes de criar as experiências dinâmicas no aplicativo que os protocolos Web3 extensíveis precisam devido às inseguranças do Javascript.

Próximas melhorias para o desenvolvimento Web3
Isso nos traz aqui: há um projeto agora que visa trazer essa experiência da Web2 para a Web3 de uma forma completamente descentralizada. O Web3API tem como objetivo apresentar uma solução única que pode ajudar a resolver todos esses problemas.

Web3API permitirá que desenvolvedores dApp integrem qualquer protocolo Web3 por meio de GraphQL, uma linguagem de consulta amplamente usada para desenvolvedores Web2. Ele permitirá que você agregue dezenas de protocolos em um dApp sem aumentar o tamanho do aplicativo e fornecerá a capacidade de interagir com o Web3 em qualquer linguagem de programação por meio da magia do WebAssembly (Rust, J Python, Go, C, C #).

Deixe um comentário

Info.CEVIU