Portal de implantação da Polkadot: por que os projetos escolhem implantar na Polkadot em vez de se tornarem uma L2?

No passado, implantar um Rollup no Polkadot nunca foi uma tarefa fácil. Isso porque, quanto mais flexível é o sistema, mais complexo costuma ser o processo de implantação: desde as atualizações do SDK, passando pelos leilões de slots, até a governança e upgrades do runtime, cada etapa pode se tornar um desafio para as equipes.

Para mudar essa situação, a Parity lançou este ano o Polkadot Deployment Portal (PDP) — uma “porta de entrada única” que cobre desde a construção, implantação até a integração. O objetivo é claro: reduzir barreiras, simplificar processos e permitir que qualquer equipe possa iniciar e operar seu próprio Rollup no Polkadot de forma rápida e estável.

Neste artigo, Santi Balaguer, líder de desenvolvimento de produto da Parity, nos leva a revisitar a evolução da experiência de implantação no Polkadot nos últimos anos, explica a filosofia de design por trás do PDP e compartilha como essa ferramenta está mudando gradualmente a forma de lançar Rollups.

Experiência de implantação no Polkadot: quanto mais flexível o sistema, mais complexo ele é

Jay: Bem-vindo ao Space Monkeys, hoje convidamos Santi Balaguer, responsável pelo desenvolvimento de produto na Parity. Hoje vamos falar sobre o PDP, qual é o nome completo do PDP?

Santi: É Polkadot Deployment Portal — Portal de Implantação do Polkadot.

Jay: Antes de começar a trabalhar no PDP, no que você esteve focado nesses quatro ou cinco anos na Parity?

Santi: Sempre estive em contato próximo com a comunidade de desenvolvedores, principalmente ajudando-os a lançar parachains e Rollups no Polkadot. Como você disse, estou na Parity desde antes das parachains serem lançadas.

Jay: Entre os projetos com os quais você teve contato, quais são mais conhecidos por nós?

Santi: Eu era responsável pelo projeto Substrate Builders, que inclui muitos projetos conhecidos. O que mais me marcou foi a equipe da Hydration. Lembro quando Jakub fez uma apresentação, explicando a ideia do Omnipool deles e os problemas que a Hydration queria resolver. Ele mostrou aquele meme clássico do “money printer goes brrrr” para explicar por que eles propuseram uma nova solução. Até hoje ainda brinco com o Jakub sobre isso.

Jay: Haha, muito bom. Você certamente viu muitos projetos terem sucesso no Polkadot, mas também deve ter ouvido falar das dificuldades deles. Pode contar quais foram os maiores desafios para implantar projetos no Polkadot nos últimos anos?

Santi: Claro. O Polkadot é um sistema muito complexo, você precisa realmente entendê-lo para que o projeto funcione bem. Essa complexidade vem justamente da flexibilidade — quanto mais flexível o sistema, mais complexo ele é.

No início, para rodar uma parachain no Polkadot, era preciso lidar com várias “atualizações disruptivas” do SDK. Naquela época, nem existia o Polkadot SDK, só o Substrate, que era diferente do que temos hoje. Depois de configurar o ambiente de desenvolvimento, era preciso buscar apoio da comunidade e participar do leilão de slots. O leilão em si já era um grande desafio, pois era necessário ter bastante apoio, e o resultado só era conhecido no último momento. Mesmo vencendo, ainda era preciso esperar três meses para a parachain realmente entrar no ar. E o slot só era alugado por dois anos. Ou seja, era preciso se dedicar tanto ao desenvolvimento técnico quanto à mobilização da comunidade para conquistar um espaço no Polkadot.

Jay: Pois é. Mas nos últimos anos, a experiência melhorou bastante. Pode falar um pouco sobre essa mudança?

Santi: Com certeza. Acho que a Parity fez um grande esforço, especialmente para reduzir as atualizações disruptivas do Polkadot SDK.

Apesar de ainda haver atualizações, hoje está muito mais estável e a compatibilidade entre versões melhorou bastante. Agora os desenvolvedores podem confiar mais na versão do SDK que usam. Algumas parachains ainda usam versões antigas do Substrate, mas continuam funcionando normalmente no Polkadot.

Outra coisa foi a introdução do Coretime (embora ele também tenha certa complexidade), mas realmente reduziu a barreira para os desenvolvedores. Facilitou muito para quem quer experimentar, diminuindo bastante o obstáculo de entrada no Polkadot. Acho que devemos aproveitar ao máximo isso.

Por que hoje os projetos escolhem implantar no Polkadot em vez de criar um L2 no Ethereum?

Jay: Apesar dos desafios, muitos já foram resolvidos. Por que você acha que hoje um projeto escolheria implantar no Polkadot? Por que não criar um L2 no Ethereum ou lançar seu próprio L1? Qual o motivo?

Santi: Essa é uma pergunta interessante. Primeiro, acho que como comunidade, precisamos comunicar e divulgar mais isso. Na minha opinião, o Polkadot é atualmente o único blockchain projetado desde o início para suportar Rollups nativamente. Ele oferece aos desenvolvedores uma infraestrutura que não existe em outros lugares.

• Por exemplo, o Polkadot oferece uma camada de disponibilidade de dados (data availability) muito grande para Rollups, enquanto no Ethereum L2 você precisa depender de sistemas externos ou “blobs” para resolver isso.

• Outro exemplo é a comunicação nativa entre parachains (cross-chain messaging), que não existe em outros Rollups. A falta desse recurso compromete a segurança do sistema.

• Em termos de performance, o Spamming já comprovou que o TPS dos Rollups do Polkadot é um dos melhores do setor.

• E sobre escalabilidade elástica, o Polkadot é o único sistema atualmente capaz de expandir ou reduzir a infraestrutura conforme a demanda. Por exemplo, se a Mythical quiser lançar um novo jogo e espera que o número de usuários aumente 10 vezes na primeira semana, eles quase não precisam mudar nada para suportar esse tráfego.

Acho que nas discussões passadas sobre “parachains e Rollups”, não conseguimos colocar o Polkadot como protagonista e perdemos uma oportunidade. Mas ainda dá tempo, ainda temos chance de trazê-lo de volta ao centro do palco.

Jay: Sim, você já me disse que o Polkadot foi projetado desde a arquitetura base para Rollups. Só que no começo não chamávamos de Rollup.

Santi: Exatamente, e tem outro ponto que muitas vezes ignoramos: a segurança compartilhada. Olhando para a história do blockchain: começou com o Bitcoin, depois veio o Ethereum. Depois, surgiram vários “novos Ethereums”, dizendo que “minha chain é melhor porque tem A, B, C”. Mas o problema é que garantir a segurança de uma nova chain é muito difícil. É preciso ter um conjunto de validadores grande e forte, o que não é fácil.

Na época, Gavin pensou: por que não oferecer segurança como um serviço, embutido na camada base? Essa é a singularidade do Polkadot. Ele não só oferece segurança compartilhada, mas também permite comunicação eficiente entre esses Rollups, algo em que o Polkadot é especialmente bom.

Como surgiu a ideia do PDP?

Jay: Muito bom. Se um Rollup quer uma camada de disponibilidade de dados nativa (e em grande escala), sem depender de soluções de outros projetos, além de alta TPS e throughput, e ainda quer comunicação perfeita com outros Rollups, o Polkadot realmente é muito atraente. Mas antes do PDP, implantar uma parachain ainda era muito complexo e demorado. Como surgiu a ideia de criar o PDP?

Santi: Na verdade, essa ideia já vinha sendo amadurecida há um tempo, embora só tenhamos começado a trabalhar nela de fato em novembro do ano passado.

Depois, nossa equipe passou a se dedicar integralmente ao projeto por volta de março ou abril deste ano, e o progresso tem sido rápido, estamos transformando a ideia em realidade. Essa demanda já existia há algum tempo, e já havia soluções semelhantes no setor. No ecossistema Ethereum, por exemplo, há o Conduit e o Gelato; no Polkadot, já houve o Tanssi, mas depois eles focaram mais no Ethereum, com uma abordagem parecida.

Vimos que no Polkadot ainda não havia uma solução consolidada, então decidimos fazer nós mesmos, para garantir que desse certo. Afinal, entendemos o Polkadot mais a fundo e sabemos como torná-lo mais acessível para desenvolvedores implantarem projetos — esse é o objetivo do PDP.

Não tomamos decisões pelos desenvolvedores, oferecemos orientação e opções

Jay: Para quem exatamente o PDP é direcionado? Lembro que no início do Polkadot havia um problema: alguns projetos já começavam fazendo Rollup, mas na verdade um contrato inteligente já seria suficiente. Que tipo de projeto realmente precisa de seu próprio Rollup?

Santi: Essa é uma boa pergunta, mas acho que não há uma resposta fixa. Até hoje ainda vemos projetos que poderiam funcionar como contratos, mas às vezes a equipe quer independência, não quer depender da infraestrutura de outra chain; às vezes, eles esperam um volume de transações muito grande no futuro, então preferem começar já com um Rollup, entre outros motivos que levam à necessidade de uma chain própria ou maior independência na infraestrutura.

Por exemplo, o Omnipool da Hydration — podemos discutir se poderia ser só um contrato, mas acho que não, faz sentido ser uma chain. Por outro lado, veja o Uniswap no Ethereum: começou como contrato, depois criou sua própria chain, mas será que realmente precisa de uma chain? Talvez não, mas eles têm suas razões comerciais.

Portanto, não há uma regra absoluta, é uma decisão técnica e comercial. Para mim, o mais importante é: não tomamos decisões pelos desenvolvedores, oferecemos orientação para que eles escolham. E, independentemente de optarem por Rollup ou contrato, devem poder experimentar facilmente.

Experiência completa do PDP: da construção à implantação e acesso, lançar um Rollup ficou simples assim

Jay: Ok, então suponha que uma equipe tomou a decisão, seja por conta própria ou com orientação de equipes como a Magenta Labs ou o time de BD. Eles decidiram implantar um Rollup no Polkadot. O que acontece quando entram no PDP? Como é o processo de implantação hoje?

Santi: No design do PDP, dividimos o processo em três etapas principais: Build (construção) — Deploy (implantação) — Access (acesso), que são interligadas.

Na etapa de “construção”, a questão central é “como começar”. Nossa ideia é: a melhor forma é por meio de templates de runtime. Atualmente, a OpenZeppelin está desenvolvendo templates, assim como as equipes do Pop CLI e ROG. O Pop CLI é basicamente uma ferramenta que você pode usar no seu computador para programar Rollups. Estamos colaborando com eles para integrar as etapas de implantação e acesso do PDP.

Por exemplo, você constrói um Rollup no Pop CLI e pode conectá-lo diretamente ao PDP para implantar — foi assim que projetamos e implementamos. Assim, o desenvolvedor pode seguir todo o processo via CLI, como no Heroku ou Vercel do Web2, ambos têm suas CLIs. Se você prefere esse método, pode usar a CLI; mas também pode usar a interface gráfica. Ambas as formas são possíveis.

Jay: Ou seja, além de construir com templates, também pode usar o Pop CLI para construir e implantar. O PDP ajuda o desenvolvedor a tomar decisões ou é só uma ferramenta para a equipe operar?

Santi: Ambos. Queremos que o PDP seja uma ferramenta de autoatendimento, para o desenvolvedor usar por conta própria. Mas se surgirem dúvidas importantes, estaremos por perto para ajudar. Claro, se alguém quiser experimentar sozinho, também não tem problema, haha.

Jay: Interessante. Pode dar exemplos de templates? Quais você mais gosta?

Santi: Por exemplo, a equipe ROG tem um template pronto chamado Pilot Revive, que você pode usar para começar. A OpenZeppelin tem o template Frontier, se quiser rodar uma chain com EVM, pode usar esse.

Jay: Legal, são opções relacionadas a contratos inteligentes.

Santi: Exato. Também há templates sem contratos inteligentes. Por exemplo, se alguém quer apenas uma chain para custodiar ativos, especialmente projetos de ativos do mundo real (RWA), também há templates específicos. Ou seja, no início já existem várias opções, e depois você pode expandir.

Jay: Dá para adicionar novos Pallets ao template conforme a necessidade?

Santi: No começo, não. A ideia é começar com o template e, depois, guiamos você para fazer upgrades do runtime. Queremos que as equipes encontrem o product-market fit gradualmente. Esse design é interessante e é uma das funções que estamos focando agora. Estamos usando uma ferramenta muito legal feita pela equipe Puppet, que compara o runtime que você vai atualizar com o já implantado, gera um relatório mostrando o que mudou, o que pode impactar os desenvolvedores e no que prestar atenção.

Jay: Sim, vi que vocês acabaram de integrar isso, muito bom.

Santi: Sim, terminamos isso esta semana. Assim, você recebe um relatório de upgrade do runtime, garantindo que o que será enviado está de acordo com o esperado. Queremos adicionar uma função para simular alguns blocos em segundo plano, testando o novo runtime. Se tudo estiver certo, avisamos “pode lançar”; se houver problemas, avisamos “teste falhou, melhor revisar”. Isso evita erros durante upgrades. Acreditamos que uma das vantagens do Polkadot é suportar upgrades flexíveis do runtime, permitindo que as equipes iterem rapidamente para encontrar o product-market fit.

Jay: Espera, essa parte já é a etapa de “implantação”? O que falamos de construção até o runtime já conta como implantação?

Santi: Sim, aqui há um pouco de sobreposição. Pode-se entender que a construção começa com o template; a implantação envolve a infraestrutura básica. Antes, era preciso ter uma equipe de DevOps para montar nós collator e cuidar da operação, mas agora, no início, não precisa se preocupar com isso. Se o projeto crescer e tiver recursos, pode montar sua própria equipe de operações, e ajudamos na migração. Mas no começo, cuidamos de tudo para você.

Jay: Quem faz isso atualmente?

Santi: Atualmente, é a Parity que fornece. Mas no futuro, os desenvolvedores poderão escolher em qual nuvem implantar, talvez até um IBP (provedor de infraestrutura). Abstrair essa camada leva tempo, então, para garantir a experiência, usamos a infraestrutura da Parity por enquanto, mas depois abriremos mais opções.

Também lançamos o conceito de BDU (Basic Deployment Unit, Unidade Básica de Implantação): sempre que você implantar um Rollup na rede de produção, provisionamos uma infraestrutura padronizada, com três nós collator (um deles serve como endpoint RPC) e um indexador.

Estamos colaborando com a Subscan, que tem uma solução open source, e planejamos integrá-la ao PDP. Assim, além do indexador, você terá um explorador de blocos. Antes, as equipes levavam muito tempo para montar tudo isso, agora resolvemos tudo em um só lugar — um design muito interessante.

Jay: Uau, parece ótimo. Isso faz parte da construção?

Santi: Isso é implantação.

Jay: Entendi, então nessa etapa o Rollup já está rodando? Já está produzindo blocos? A equipe pode fazer upgrades do runtime para iterar e buscar o product-market fit? E depois vem a última etapa, “Acesso (Access)”, certo? O que é isso?

Santi: Exato! Access é o destaque do Polkadot, acho que é onde o Polkadot realmente agrega valor único para equipes de Rollup. Construção e implantação envolvem runtime e infraestrutura, que todos conseguem aprender rápido, mas usar de fato as características do Polkadot faz a diferença. Por exemplo, o Coretime faz parte do Access, e o PDP compra Coretime antecipadamente, assim, quando o desenvolvedor implanta um Rollup, já pode usá-lo imediatamente, sem esperar 28 dias para começar a produzir blocos — isso melhora muito a experiência do usuário.

Jay: Se eu quiser implantar, preciso comprar Coretime no PDP?

Santi: Nós compramos para você e depois cobramos. Na verdade, oferecemos diferentes opções de Coretime. Se quiser começar com tudo, pode usar um core completo. Também oferecemos “core fatiado”, ou seja, uma parte do core — se quiser testar gastando pouco, pode usar só uma fração.

Jay: Esse recurso já está disponível?

Santi: Já está disponível no PDP. Já está rodando nas redes Westend e Paseo. O Paseo acabou de lançar o core fatiado, e no Westend você pode negociar uma parte do core — a desvantagem é que o tempo de produção de blocos aumenta, mas o custo cai muito, facilitando testes. Se funcionar bem, pode fazer upgrade para core completo e ter blocos a cada seis segundos, tudo pelo PDP. Mas ainda precisamos resolver como usar o Polkadot de forma eficiente na integração. O Polkadot Hub, como módulo funcional importante, está prestes a ser lançado e estamos muito animados com isso.