A primeira decisão de Gavin após seu retorno: Parity não vai mais focar apenas na infraestrutura, agora vai criar produtos!

Nos últimos dois anos, a Polkadot tem enfrentado um dilema fundamental: a tecnologia da cadeia já é de nível mundial, mas as aplicações realmente funcionais são extremamente limitadas.

O DeFi pode funcionar, mas outros cenários do Web3 estão praticamente parados. Desenvolvedores externos não começaram a “construir aplicações na Polkadot” como esperado, e a expansão do ecossistema encontrou um gargalo.

Assim, quando Gavin voltou a liderar a direção da Parity, uma coisa tornou-se mais clara do que nunca — se ninguém criar aplicações Web3, então a Parity terá de ser a primeira a fazê-lo.

Isto não é simplesmente “fazer alguns demos”. É uma mudança estratégica — de “a Parity cuida da infraestrutura, as aplicações ficam a cargo do ecossistema” para “a Parity cria protótipos de aplicações que realmente possam substituir o Web2, validando pessoalmente o valor da tecnologia Polkadot”.

Nesta longa entrevista da série “Space Monkeys”, o vice-presidente de engenharia Pierre explicou sistematicamente pela primeira vez:

• Por que o modelo de construtores externos falhou 
• Por que é necessário refazer produtos 
• Por que o Polkadot Hub deve ser “primeiro EVM, depois PVM” 
• Por que Gavin está a impulsionar “iterações a cada duas semanas” 
• Por que a Polkadot está a reconstruir toda a stack de aplicações de computação, armazenamento, notificações e identidade descentralizadas 

Verás claramente que a Parity está a construir uma “camada descentralizada de substituição do AWS + Web2”. Isto determinará se a Polkadot poderá recuperar a liderança na segunda era.

Por que a Parity decidiu “criar aplicações por conta própria”?

Jay: Bem-vindo a mais uma edição do programa “Space Monkeys”! O convidado desta vez é Pierre Aubert, vice-presidente de engenharia da Parity. É uma grande sorte poder convidá-lo novamente, já faz algum tempo desde a última vez que esteve connosco. Na altura, ele tinha acabado de entrar na Parity. Hoje vamos falar sobre o que ele aprendeu neste período, as mudanças que observou e as direções futuras. Bem-vindo de volta, Pierre!

Pierre: Obrigado, olá a todos!

Jay: Antes, trabalhaste na Google, já pensavas na forma dos sistemas de rede Web3 e no papel que poderias desempenhar neles. Agora, que aprendizagens tiraste?

Pierre: Agora tenho uma compreensão mais clara de como o sistema funciona como um todo, e também algumas boas ideias sobre o que podemos fazer. O potencial deste sistema é enorme, há muitas coisas possíveis, mas a implementação é difícil.

Atualmente, o estado do Web3 é que, exceto pelo DeFi (finanças descentralizadas), o progresso noutras áreas é lento. Recentemente, o Gav voltou à empresa como líder e decidiu que a empresa deveria focar-se mais na criação de produtos, o que considero a direção correta.

Há dois anos, a nossa ideia era que a Parity construiria a infraestrutura blockchain e as aplicações seriam desenvolvidas por terceiros. Mas, na prática, este plano não evoluiu como esperado. Agora, a nossa estratégia é fazer nós mesmos, primeiro alguns protótipos de aplicações pequenas, para demonstrar como usar sistemas descentralizados e provar que esta arquitetura pode realmente criar produtos úteis.

Portanto, o primeiro passo é criarmos estas aplicações e usá-las internamente, o chamado “dogfooding” (testar internamente). Muitas aplicações iniciais vão focar-se nas ferramentas que usamos no dia a dia, com o objetivo de substituí-las por sistemas descentralizados. Quando estas aplicações estiverem suficientemente maduras internamente, serão lançadas para os utilizadores. Por exemplo, na Web3 Summit, na verdade não usamos a nossa própria tecnologia: os bilhetes foram comprados através de empresas Web2 tradicionais, o pagamento foi em euros; o sistema de controlo de acesso do local também era arquitetura Web2. Este é um cenário onde podemos intervir, usando a nossa própria tecnologia para construir um sistema mais seguro e aberto.

Jay: Mas estes sistemas já são muito eficientes e estáveis. Qual é o sentido de mudá-los para sistemas Web3?

Pierre: Se achas que sistemas centralizados satisfazem as necessidades, tudo bem. Especialmente em cenários como bilhetes. Mas em casos como controlo de acesso, as vantagens da descentralização tornam-se óbvias. Por exemplo, num hotel, recebes um cartão para abrir a porta, mas na verdade, muitas pessoas no hotel podem copiar o cartão e deixar estranhos entrarem. Num sistema Web3, só tu podes “cunhar” o teu certificado de acesso exclusivo, aumentando muito a segurança.

Portanto, depende do cenário de aplicação. Em alguns casos, é fácil perceber porque a descentralização é melhor. Por exemplo, não gosto dos serviços Web tradicionais: quase a cada seis meses, uma empresa é atacada por hackers e os meus dados são expostos — endereço, senha, informações bancárias, tudo vazado. O motivo é simples: estes sistemas não são suficientemente seguros.

O que eu quero é que a Polkadot consiga “segurança por padrão”: porque os dados pertencem a mim. Por exemplo, quando compro um bilhete, não preciso de te dizer o meu endereço residencial. Só preciso de fornecer uma prova de conhecimento zero para provar que moro num determinado local, mas não saberás o meu endereço exato. Assim, mesmo que o teu sistema seja hackeado, as minhas informações reais não serão expostas. Não quero que os meus dados pessoais sejam recolhidos e vazados por todo o lado. Pode ser por questões de segurança ou apenas por privacidade. Em suma, mesmo em sistemas já muito maduros, se conseguirmos descentralizá-los, eles ainda ficarão melhores e mais seguros.

Como a Parity melhora a eficiência do trabalho?

Jay: Nos últimos dois anos, investiram muito na construção de sistemas descentralizados. Desde que assumiste como vice-presidente de engenharia, em que aspetos a Parity melhorou?

Pierre: Na verdade, o que fiz foram coisas básicas de “gestão”, nada complicado, apenas organizar o sistema de gestão. O resultado foi muito bom, a produtividade aumentou bastante. São operações básicas, como estabelecer processos padronizados. Especialmente porque os engenheiros gostam de ambientes organizados e regras claras. Quando os processos e responsabilidades estão claros, a justiça surge naturalmente. Por exemplo, promovemos quem realmente se destaca, quem tem melhor desempenho recebe salários mais altos, e este processo é fiável e transparente. Os engenheiros gostam desta justiça: se ganhas mais do que eu, é porque és realmente melhor. Esta justiça foi reconhecida por todos, eu próprio gosto deste método e acho que é assim que uma organização saudável deve funcionar.

Jay: Para quem lidera equipas, mesmo pequenas, tens alguma dica prática, por exemplo, como avaliar funcionários, decidir promoções ou delegar? Em que características do crescimento dos funcionários te focas?

Pierre: Damos mais importância aos resultados do que ao processo. Por exemplo, há quem trabalhe muito e faz questão que todos saibam o quanto se esforça, mas no fim não entrega resultados. Por outro lado, há quem trabalhe de forma inteligente, talvez só vinte horas por semana, mas resolve os problemas e gera impacto real. Isso é o que mais valorizamos. Resumindo: trabalhar de forma inteligente é mais importante do que trabalhar arduamente.

Jay: Notaste algum padrão comum entre os funcionários que não conseguem entregar resultados? Podem estar sempre ocupados, mas não produzem. Que características têm normalmente?

Pierre: Na maioria das vezes, não é um problema pessoal, mas sim de gestão. Normalmente, é porque não têm clareza sobre os objetivos do seu trabalho, não sabem exatamente o que devem fazer. Esta “falta de clareza” torna o trabalho muito difícil. Especialmente num ambiente como o da Parity, onde todos são bastante competentes, se alguém não entrega, geralmente é por falta de direção.

Portanto, tornar os objetivos claros e definidos é o mais importante. Outro ponto fundamental é que, às vezes, os membros da equipa não sabem a quem recorrer quando têm problemas. Antes, a Parity não era boa nisto, mas agora melhorámos: está claro quem é responsável por cada coisa. No fim, a pessoa responsável tem de tomar decisões: “Vamos pela esquerda ou pela direita?” Assim que isto está resolvido, a equipa avança sem problemas.

Jay: Concordo, já passei por isso. Antes, havia sempre alguém a fugir à responsabilidade: “Esta decisão é de outra pessoa, tenho de esperar que decidam para continuar.” Assim, o trabalho ficava parado.

Pierre: Sim, clarificar responsabilidades é fundamental. E não é complicado, muitas vezes basta escrever e explicar. Outro fenómeno negativo é quando alguém, no sucesso, diz “foi graças a mim”; mas se falha, culpa os outros. Isso não é aceitável. Não podes querer o crédito pelo sucesso e culpar outros pelo fracasso.

Portanto, a “clareza” traz benefícios, tornando a organização mais fluida. Não muda muito o teu dia a dia, mas a longo prazo, toda a empresa torna-se mais eficiente.

Estratégia do Polkadot Hub: primeiro EVM, depois PVM

Jay: Vamos falar do projeto Polkadot Hub. Consideras que foi um sucesso ou um fracasso?

Pierre: Diria que sim e não. Em termos de qualidade do produto, é um projeto de sucesso, o resultado final é bom.

Mas na forma de trabalhar, há pontos a melhorar. Por exemplo: no início, decidimos usar a tecnologia PVM, porque tem melhor desempenho. Mas, após um ano, percebemos que a maioria dos grandes contratos inteligentes do Ethereum não funcionava no PVM, o que nos surpreendeu. Deveríamos ter testado isto antes, mas subestimámos a complexidade do ecossistema EVM. Depois percebemos que era preciso suportar EVM. Então, tivemos de “retroportar” o suporte EVM para o sistema, tornando o projeto mais complexo.

Além disso, subestimámos a complexidade de muitos aspetos do ecossistema Ethereum, como frameworks de teste (como Anvil), mapeamento de Gas, etc. Portanto, aprendemos uma lição importante: antes de começar um projeto, é preciso escrever e pensar bem. Especialmente em projetos complexos, não se pode avançar só porque “parece simples”.

Hoje, no setor cripto, muitos dizem: “Não importa, faz logo!” Sempre que alguém diz isso, peço que escreva um documento. Muitas coisas que parecem simples são, na prática, muito complicadas, e o projeto acaba por demorar e exigir mais recursos do que o previsto.

No geral, o Hub é um sucesso em desempenho e qualidade, mas ainda não atingimos o ideal em práticas de engenharia, o ciclo de desenvolvimento foi demasiado longo.

Jay: Entendi. Participaste na implementação do Hub? Ouvi dizer que têm tentado atrair outros projetos para migrar para lá.

Pierre: Não sou o responsável técnico direto, mas selecionei e formei a equipa certa, além de definir padrões de qualidade para garantir a estabilidade do sistema. Estou especialmente satisfeito com a migração de ativos, que exigiu muito esforço e foi feita de forma muito profissional. Isso mostra que a Parity já tem capacidade para grandes migrações sem afetar os utilizadores. Não é trabalho de “startup”, mas sim de nível de grande empresa. Levou tempo e recursos, mas provámos que, quando decidimos fazer, conseguimos atingir um nível muito alto, o que é um sinal positivo para o futuro: se conseguirmos manter este padrão nos próximos projetos, a tecnologia não será um problema.

Jay: O objetivo deste ecossistema é facilitar a implantação de projetos que já conhecem EVM ou contratos inteligentes Solidity. Que projetos vão entrar nesta fase inicial? Como será o processo de implantação? É direto no EVM ou vão migrar para PVM?

Pierre: Depende. Para grandes contratos do Ethereum, eles não têm motivação para migrar para PVM. Então, primeiro vão implantar no EVM, que é compatível e simples, basta implantar.

Jay: Refere-se àqueles protocolos DeFi “blue chip”, certo? Estão em todas as principais cadeias.

Pierre: Estes projetos não vão ganhar muito em desempenho com o PVM, pois não precisam de muita computação. Os contratos inteligentes deles geralmente só: leem saldo de conta → executam alguma lógica → escrevem o resultado. Não há muita computação, o gargalo está na leitura e escrita de dados, e aí o desempenho do EVM já é suficiente. A vantagem do PVM é lidar com tarefas de computação intensiva, permitindo no futuro executar na cadeia tarefas que hoje só podem ser feitas off-chain. É aí que o PVM realmente faz diferença.

Jay: Por exemplo, que tipo de coisas?

Pierre: Podes calcular ZK-SNARK em tempo real na cadeia. Na verdade, podes fazer muitas coisas no PVM que não são possíveis no EVM. Acho que isso é bom para o ecossistema cripto, pois colocar mais coisas on-chain reduz práticas estranhas off-chain e a dependência de oráculos de terceiros.

No geral, colocar mais lógica on-chain traz mais benefícios do que desvantagens. Se o mundo cripto copiar o Web2, as pessoas vão sempre usar toda a CPU disponível; se deres mais recursos de computação, as pessoas vão sempre encontrar formas de os usar.

Agora temos o sistema de computação Polkadot, estamos a construir sistemas de armazenamento e notificações

Jay: Ok. Falando da transição para produtos, Gavin mencionou numa reunião interna da Parity que o ideal seria fazer iterações de produto a cada duas semanas, lançando rapidamente muitos produtos. Esses produtos vão usar PVM e Hub? Ou vão ser implantados noutras stacks tecnológicas?

Pierre: Depende do produto, mas a maioria vai usar algum tipo de contrato inteligente.

Jay: Ah, ok. Então a maioria dos produtos não vai começar com a solução rollup + parachain, certo?

Pierre: Depende, ainda é cedo para dizer. Serviços de armazenamento ou notificações provavelmente serão parachains separados, mas para cenários como controlo de acesso, contratos inteligentes já são suficientes.

Jay: Como está o progresso do projeto de armazenamento? Sinto que já tentámos várias soluções diferentes, mas ainda não temos uma solução unificada.

Pierre: O armazenamento é uma das tarefas mais complexas e importantes. Criar um sistema de armazenamento descentralizado utilizável. Só definir o padrão de “utilizável” já é difícil, por isso são necessárias várias iterações. Há uma equipa no ecossistema a trabalhar nisso, a Moonbeam também está envolvida.

Jay: Referes-te a coisas como o DataHaven?

Pierre: Sim, como o DataHaven, e também o Eiger (que está a desenvolver algumas primitivas de baixo nível). Internamente, a Parity também está a desenvolver um armazenamento embutido na cadeia; há ainda projetos como o JamDA. Agora há muitas equipas a avançar com projetos de armazenamento descentralizado, cada uma com características diferentes, e talvez precisemos de mais de uma solução: precisamos de armazenamento descentralizado barato (por exemplo, para carregar fotos, não pode ser caro), e também de armazenamento mais “rápido”, para leituras e escritas frequentes, mas sem necessidade de grandes volumes de dados.

Portanto, provavelmente coexistirão várias soluções de armazenamento, ou um software configurável em diferentes modos. Agora, a ideia é usar o JamDA como armazenamento de curto prazo/temporário: os dados são temporários, por exemplo, expiram após 28 dias.

(A grafia de JamDA pode estar incorreta, agradecemos correções)

Jay: A menos que renoves o prazo?

Pierre: Sim, pode ser renovado. Ou podemos construir um sistema descentralizado distribuído em larga escala sobre o JamDA, permitindo escolher manter dados a longo prazo. Por exemplo, escreveste um artigo científico e queres mantê-lo público por muito tempo, então usas armazenamento de longo prazo. Assim, pode ser um sistema de duas fases: “temporário + longo prazo”.

Jay: Que características este sistema terá que o IPFS não consegue oferecer?

Pierre: Por exemplo, o IPFS não garante disponibilidade. Podes carregar um documento, mas não há garantia de que estará sempre acessível no futuro.

Jay: As soluções que mencionaste vão, no fim, ser protegidas pela segurança da Polkadot? Ou seja, vão funcionar sobre o modelo de segurança da Polkadot?

Pierre: No fim, sim, mas no início talvez não.

Jay: O que queres dizer?

Pierre: Por exemplo, podemos começar por usar sistemas prontos como o Filecoin, acrescentando uma camada por cima para ver se satisfaz as necessidades. Quando a nossa solução estiver madura, substituímos gradualmente o Filecoin ou outras soluções. Ainda não está totalmente definido.

O próximo passo é implementar as funções embutidas na cadeia, depois o JamDA, e gradualmente integrar outras soluções, por isso ainda vai demorar até termos uma solução estável.

Armazenamento é diferente de computação: se a computação falhar, podes repetir, estamos habituados (por exemplo, se o browser falha, basta atualizar); mas armazenamento é muito mais complexo, por exemplo, se carregas uma foto encriptada, queres poder recuperá-la depois, não precisa ser imediato, mas tem de ser 100% garantido que podes fazer backup. Por isso, as expectativas para armazenamento são mais altas do que para computação.

Jay: Sim. Estamos cada vez mais perto de criar uma “nuvem” ou “servidor” descentralizado, todos os componentes estão a ser aperfeiçoados gradualmente.

Pierre: Exatamente, passo a passo. Vais ver que estamos a reconstruir de forma descentralizada muitos serviços comuns no Web2, com características diferentes, mas essencialmente do mesmo tipo. Agora temos o sistema de computação Polkadot e estamos a construir sistemas de armazenamento e notificações.

Jay: Referiste há pouco o “sistema de notificações”, o que significa exatamente?

Pierre: Por exemplo, tens uma aplicação, quando alguém responde, comenta o teu documento ou interage contigo, precisas de receber uma notificação, certo? Isso é um sistema de notificações. Mas o problema é que, na comunicação pela internet, normalmente estamos ambos atrás de firewalls, o que significa que não posso ligar-me diretamente a ti. O método comum é usar um servidor centralizado como intermediário. Esse servidor “abre a porta” para nós, estabelece a ligação e só então podemos comunicar ponto a ponto.

Jay: Como criar uma sala de chat privada, por exemplo.

Pierre: Sim, exatamente. O que queremos agora é substituir esse servidor central por uma solução descentralizada, mantendo a mesma capacidade de comunicação. A funcionalidade é semelhante, mas será mais complexa, pois queremos algumas características extra, como: não depender de nenhuma autoridade centralizada, não gerar metadados rastreáveis. Por exemplo, ao conversar no Signal, outros não sabem o que dizemos, mas sabem “que estou a falar contigo”. No sistema que queremos construir, nem sequer será possível provar “com quem estou a falar”.

Siga o canal PolkaWorld, na próxima publicação partilharemos mais da entrevista com Pierre!