Gavin Wood: Após o EVM, o JAM se tornará o novo consenso da indústria!

Dando continuidade ao artigo de ontem, compartilhamos a segunda parte da entrevista mais recente de Gavin Wood!

As blockchains públicas podem competir entre si, mas os desenvolvedores só se reúnem em torno de consensos.

Dez anos atrás, o EVM inventado por Gavin tornou-se consenso; desde então, toda a indústria passou a ter uma “linguagem” comum.

Dez anos depois, Gavin lança o JAM, esperando que ele se torne a próxima “linguagem”.

Não é uma ferramenta de uma única blockchain, mas sim um protocolo subjacente que permite que todas as blockchains obtenham escalabilidade elástica, colaboração distribuída e interoperabilidade entre redes.

Qualquer construtor pode criar seu próprio sistema sobre ele, permitindo até que diferentes tokens e ecossistemas compartilhem a mesma rede de segurança.

Para os desenvolvedores, isso significa uma coisa:

Construir a próxima geração de blockchains não exige começar do zero, JAM é o novo ponto de partida padrão.

O clima do JAM é algo que não sentia desde 2015

Pala Labs: Atualmente, a turnê global do JAM já passou da metade. Você foi pessoalmente a várias partes do mundo, encontrando desenvolvedores ativos do JAM, além de apoiadores interessados e entusiasmados. Como você se sente sobre esse modelo de construção descentralizado do JAM?

Gavin: Até agora, estou muito otimista com o progresso geral do JAM. Os desenvolvedores do JAM demonstram um entusiasmo e proatividade raramente vistos durante o desenvolvimento do Polkadot— eles realmente amam o projeto e estão dispostos a assumir responsabilidade real pelo seu trabalho.

Para entender essa diferença, é preciso voltar ao modelo de desenvolvimento do Polkadot. Na época, o desenvolvimento era feito dentro de uma estrutura corporativa. Embora houvesse pessoas engajadas e dispostas a assumir responsabilidades, essa “proatividade” era, em parte, um resultado natural do sistema—você recebe um salário, assumir responsabilidades é parte do seu trabalho.

O JAM é completamente diferente. Os desenvolvedores atuais não têm salários estáveis; eles investem seu próprio tempo, energia e assumem riscos. No futuro, podem até receber subsídios ou recompensas, mas, antes disso, precisam entregar resultados. Em contraste, a lógica de contratação de funcionários por empresas é o oposto—a empresa paga altos salários primeiro e assume o risco de o funcionário não ser adequado.

Os desenvolvedores do JAM assumem o risco por conta própria, e esse investimento já diz muito. Você está diante de uma equipe que realmente constrói por uma visão e entrega resultados. Nesse ambiente, você vê uma convicção rara—algo difícil de encontrar em funcionários de empresas tradicionais.

No fim das contas, a estrutura organizacional das empresas tradicionais é essencialmente um sistema de poder de cima para baixo: o chefe detém o poder máximo de decisão, delega para executivos, que repassam tarefas aos líderes de equipe, e estes, por fim, distribuem para os funcionários de base. Todos precisam prestar contas ao superior, seguir ordens, e seu desempenho depende da avaliação do chefe.

Mas o JAM não é nada assim.

Nesse projeto, sou mais um consultor, respondendo perguntas quando necessário—às vezes de forma breve, até um pouco direta, mas, no geral, amigável. Além disso, sou responsável por escrever o gray paper e tentar validar se o design é viável, pelo menos convencendo a mim mesmo e, espero, também aos outros sobre a razoabilidade das propostas.

No entanto, quem realmente impulsiona o JAM são as equipes de desenvolvimento. Elas se envolvem por paixão, para ganhar experiência ou por acreditar no valor comercial futuro do sistema. Mas, independentemente da motivação, estão construindo o sistema de forma ativa e espontânea.

Esse clima é algo que não sentia desde 2015, muito parecido com os primeiros dias do Ethereum—todos participavam com entusiasmo; mesmo que o gray paper fosse extremamente difícil, estavam dispostos a gastar muito tempo entendendo e transformando-o, passo a passo, em software funcional.

Após o EVM, JAM será o novo consenso da indústria

Pala Labs: Parece que o JAM não é apenas um projeto tradicional de blockchain, mas vai além do escopo de blockchain e criptomoedas, até maior que o Polkadot. Se você tivesse que explicar o JAM para alguém que não conhece o Polkadot, como faria? Para que serve essa ferramenta?

Gavin: Simplificando, JAM é um protocolo chamado “Join Accumulate Machine”, cuja especificação completa está claramente descrita no gray paper do JAM. Segundo o gray paper, JAM combina as principais vantagens do Polkadot e do Ethereum:

• Por um lado, herda o mecanismo de criptoeconomia do Polkadot—é esse mecanismo que sustenta a alta escalabilidade do Polkadot;
• Por outro lado, adota uma interface e modelo de serviços mais próximos do Ethereum, permitindo que a cadeia principal execute operações programáveis.

Diferente das arquiteturas tradicionais, que só permitem programabilidade em módulos de computação de alto desempenho, o JAM vai além. Ele permite que as unidades de computação sejam programáveis, bem como o “processo de colaboração” e o “efeito acumulado” entre diferentes módulos—daí o nome “Join Accumulate Machine”.

Embora o JAM tenha sido inicialmente proposto como uma atualização do Polkadot e tenha recebido amplo apoio da comunidade, sua concepção vai muito além do Polkadot. É uma arquitetura subjacente altamente abstrata, independente de qualquer blockchain específica, podendo ser vista como o design fundamental da próxima geração de blockchains.

A principal capacidade do JAM é distribuir e agendar cargas de trabalho de forma segura e distribuída em toda a rede, proporcionando escalabilidade elástica nativa para as aplicações que rodam sobre ele—algo que nenhuma outra solução do setor consegue atualmente.

Além disso, o JAM permite a interconexão de múltiplas instâncias de rede, expandindo o alcance das aplicações além dos limites de uma única blockchain. Isso faz dele não apenas uma nova arquitetura de blockchain, mas também um possível paradigma para soluções de escalabilidade de próxima geração.

Podemos olhar para o JAM além do “projeto de atualização do Polkadot”. Como insisti ao escrever o gray paper: sou melhor em trabalhos inovadores do zero do que em evoluir sistemas existentes. Por isso, o design do JAM não é uma extensão gradual de estruturas existentes, mas uma construção totalmente nova a partir dos princípios mais básicos.

Embora o JAM aproveite alguns resultados técnicos do Polkadot, também incorpora muitos conceitos e mecanismos novos. Sistematizei tudo isso no gray paper para desvinculá-lo do contexto do Polkadot e transformá-lo em uma arquitetura subjacente de valor mais amplo—um pouco como o conjunto de instruções x64 da época.

Falando nisso, vale relembrar a história do x64. A Intel inicialmente projetou o conjunto de instruções x86 para seus processadores, evoluindo do 8086 ao 80286, 80386 e depois à série Pentium, tornando-se padrão para PCs compatíveis com IBM e dominando o mercado de desktops por muito tempo.

Mas quando a indústria se preparava para a era de 64 bits, a solução própria da Intel era avançada demais e não foi aceita pelo mercado. A AMD, considerada “seguidora” na época, projetou uma extensão de 64 bits mais simples e viável baseada no conjunto de instruções de 32 bits da Intel—o AMD64. O mercado escolheu o caminho da AMD, e a Intel teve que abandonar sua própria solução e adotar a abordagem da AMD. A partir daí, os papéis de líder e seguidor se inverteram.

Essa história é significativa: embora a Intel tenha adotado a tecnologia da AMD, não quis usar o nome “AMD64”, e o setor acabou adotando o termo neutro “x64”. Hoje, ambas as empresas constroem produtos baseados nessa arquitetura unificada.

Mencionei esse caso para ilustrar: acredito que o JAM pode se tornar o “x64” do setor de blockchain. Ele é visto como uma evolução racional do setor, especialmente adequado para blockchains públicas que valorizam resiliência, descentralização e outros princípios do Web3. O protocolo mantém intencionalmente um design aberto em muitos aspectos, como modelo de governança, mecanismo de emissão de tokens e sistema de staking, permitindo que diferentes projetos de blockchain personalizem esses módulos e até escolham sua própria linguagem de programação ao adotar o JAM.

O PVM usado pelo JAM é um conjunto de instruções altamente genérico. Blockchains que adotam essa arquitetura podem aproveitar a escalabilidade e a composabilidade do JAM, além de, no futuro, possibilitar colaboração e integração entre diferentes blockchains via JAM.

Recentemente, venho pensando em um caminho—espero publicar em breve—sobre como permitir que duas blockchains baseadas no JAM, mas com tokens diferentes, possam se integrar ainda mais: mantendo seus próprios sistemas de tokens, mas compartilhando a mesma rede de segurança. Acredito que, mesmo que não seja a forma final da indústria de blockchain, esse caminho técnico já seria uma grande virada no setor.

De uma perspectiva mais ampla, o JAM provavelmente se tornará, como as tecnologias iniciais do Ethereum, uma base comum para toda a indústria. O EVM do Ethereum já foi amplamente adotado ou parcialmente incorporado por muitas blockchains, e seu formato de transação e lógica de execução tornaram-se padrões de fato. O JAM também tem esse potencial de ser uma tecnologia neutra entre tokens e redes.

Como enfatizei repetidamente, o JAM deve ser uma tecnologia subjacente neutra. Estou convencido de que seu design é suficiente para sustentar o desenvolvimento estável da indústria de blockchain pelos próximos cinco a dez anos, ou até mais. Claro, o sistema continuará evoluindo. Se provas de conhecimento zero (ZK) se tornarem viáveis economicamente, alguns módulos do JAM poderão ser substituídos. Mas, no geral, como uma inovação sistêmica razoável, o JAM não ficará restrito ao ecossistema Polkadot; qualquer blockchain que reconheça seu valor pode adotá-lo dentro de sua própria estrutura de governança.

Além disso, desde o início, o JAM seguiu os princípios de descentralização e “normas primeiro”: primeiro publica a especificação do protocolo, depois organiza a implementação e incentiva mais de 35 equipes independentes ao redor do mundo a participar do desenvolvimento, distribuindo naturalmente o conhecimento e o controle. Esse método ajudará o JAM a se tornar uma tecnologia central realmente neutra e amplamente adotada no mundo Web3.

No “pós-era da confiança”, Gavin diz aos jovens desenvolvedores: Web3 não é uma escolha, é uma responsabilidade

Pala Labs: Conhecemos muitos desenvolvedores entusiasmados com o JAM, muitos deles bem jovens, talvez ainda estudantes, representando uma nova força no setor. Se você pudesse dizer algo para esse grupo—que talvez se pareça com você há 20 anos, apaixonado por criar e sonhando com uma sociedade e um mundo livres—o que você diria?

Gavin: Entre cedo e aprofunde-se. Você deve seguir seu próprio julgamento de valores. Se você acredita em livre arbítrio e soberania individual, princípios centrais do Iluminismo, então deve agir por conta própria—ninguém pode assumir essa responsabilidade por você.

Pala Labs: A inteligência artificial também pode trazer problemas de falsificação de identidade?

Gavin: O sistema de confiança da sociedade atual está desmoronando rapidamente. Por volta de 2014 e 2015, surgiu o termo “pós-verdade”, significando que as pessoas não acreditam mais na existência de uma verdade objetiva. Embora essa ideia tenha algum valor de observação, filosoficamente não se sustenta. Sempre acreditei: a verdade existe, e a humanidade tem o dever de buscá-la. Se uma decisão não se baseia nos fatos mais razoáveis e confiáveis do momento, está fadada ao erro.

Ainda assim, já entramos em uma “pós-era da confiança”: as pessoas ou desconfiam de tudo, ou depositam confiança cegamente em agitadores perigosos. Ambos os extremos corroem a racionalidade da sociedade. Nesse contexto, a inteligência artificial só amplifica o problema.

Claro, a IA tem muitos aspectos positivos, como aprimorar a comunicação e enriquecer a criação artística. Eu mesmo uso IA como DJ e na criação de música. Mas, nos sistemas socioeconômicos, políticos e geopolíticos, os riscos da IA não podem ser subestimados.

Não podemos depositar nossas esperanças na regulação. Regulamentações geralmente só restringem o uso de IA por indivíduos cumpridores da lei em sociedades livres, mas não conseguem impedir organizações mal-intencionadas, nem evitar que países não livres usem IA para atacar sociedades livres. Portanto, só regulação não resolve.

O que realmente precisamos é de uma base tecnológica mais forte e sólida para limitar os impactos destrutivos potenciais da IA—seja para lidar com abusos internos ou ameaças externas maliciosas.

Na minha opinião (embora possa ser um pouco tendenciosa), só a tecnologia Web3 pode realmente resolver esse problema. O motivo é simples: a essência da IA é “enfraquecer a verdade, fortalecer a confiança”. Quando dependemos da IA, na verdade estamos confiando nas organizações que fornecem os modelos e serviços—sejam instituições que treinam grandes modelos ou empresas que operam modelos em servidores fechados e retornam resultados.

Mas não podemos auditar os dados de treinamento do modelo, nem saber por que ele dá determinada resposta; nem mesmo quem treinou o modelo entende totalmente seu funcionamento interno. Comparativamente, é mais confiável que cada pessoa verifique os fatos por si mesma. No entanto, à medida que a sociedade depende cada vez mais da IA e confia nela facilmente, as pessoas acabam caindo em uma “confiança cega que parece objetiva”.

Já que a lógica da IA é “menos verdade, mais confiança”, precisamos equilibrá-la com a tecnologia Web3, que é “menos confiança, mais verdade”.

Em uma sociedade livre, o que realmente deve ser feito não é aumentar a regulação sobre o Web3, mas agir rapidamente: reduzir restrições desnecessárias e fornecer apoio e financiamento reais para quem constrói a infraestrutura do Web3.

Pala Labs: Agora muitos novos desenvolvedores estão entrando no projeto JAM. Você pode prever como será o desenvolvimento nos próximos cinco ou seis anos?

Gavin: Prever o futuro sempre é difícil, mas posso compartilhar minha experiência. No final de novembro de 2013, eu morava em Londres e tinha um amigo chamado “Johnny Bitcoin”, que também era amigo do Vitalik. Todo mês íamos ao bar tomar uma cerveja e conversar. Numa dessas vezes, ele me disse que seu amigo Vitalik estava trabalhando em um novo projeto baseado no Bitcoin, chamado Ethereum, e procurava alguém para desenvolver o código. Brinquei: “Claro, deixa comigo.” Sempre achei que programava bem, então ele sugeriu: “Se você é tão bom, por que não desenvolve o Ethereum?” Assim, tornei-me um dos desenvolvedores do Ethereum. Na época, o white paper do Ethereum era algo entre um documento de visão e uma especificação formal, não totalmente inequívoco, mas com detalhes técnicos suficientes para ser viável. Nos quatro ou cinco meses seguintes, todos trabalhavam em versões compatíveis, o que levou ao yellow paper do Ethereum—a especificação formal do protocolo. Eu era um desenvolvedor independente responsável por esse protocolo, junto com Vitalik e Jeff, que cuidava da versão em Go do Ethereum. Depois, tornei-me cofundador do Ethereum, fundei a Parity e continuei desenvolvendo mais produtos relacionados.

Minha trajetória no blockchain começou assim—como desenvolvedor independente, usando meu tempo livre para criar um protocolo do zero.

Por isso, não sei se as equipes do JAM vão aproveitar tanto quanto eu essa jornada de desenvolvimento. Mas, para mim, foi o início da minha vida; não havia outra escolha, só podia começar dali, e ficou provado que o potencial desse caminho era muito maior do que eu imaginava.

Claro, não se trata apenas de programar, mas também de aprender a se comunicar: conversar com investidores em potencial, apresentar projetos, pensar em cenários de aplicação baseados no protocolo, escrever contratos inteligentes, promover o projeto, aconselhar outros, etc. Além de programar, há muito a fazer, mas programar é o ponto de partida e o núcleo de tudo.

Nos últimos 11 anos, quase nunca parei de programar por muito tempo. Na verdade, isso começou ainda antes; desde os oito ou nove anos, nunca parei muito tempo—a maior pausa foi uma viagem a pé pela América Central, que durou apenas três meses.

Esse foi o caminho que segui. Se esses novos desenvolvedores também tiverem paixão e capacidade suficientes, acredito que nada pode impedi-los de trilhar esse caminho—só que, desta vez, o objetivo é o JAM, não o Ethereum!