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

No passado, implantar um Rollup na 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 atualizações do runtime, cada etapa pode se tornar um desafio para a equipe.

Para mudar esse cenário, a Parity lançou este ano o Polkadot Deployment Portal (PDP) — uma “porta de entrada tudo-em-um” 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 lançar e operar rapidamente seu próprio Rollup na Polkadot de forma estável.

Neste artigo, Santi Balaguer, responsável pelo desenvolvimento de produto da Parity, nos leva a revisitar a evolução da experiência de implantação na Polkadot nos últimos anos, explica o conceito por trás do PDP e compartilha como essa ferramenta está mudando passo a passo a forma de lançar Rollups.

Experiência de implantação na 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 da Parity. Vamos falar sobre o PDP. Qual é o nome completo do PDP?

Santi: É Polkadot Deployment Portal — Portal de Implantação da 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 na Polkadot. Como você disse, estou na Parity desde antes do lançamento das parachains.

Jay: Entre os projetos com os quais você teve contato, quais são os 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 um meme clássico do “money printer goes brrrr” para explicar por que estavam propondo uma nova solução. Até hoje, ainda brinco com Jakub sobre isso.

Jay: Haha, muito bom. Você certamente viu muitos projetos terem sucesso na Polkadot e também ouviu sobre suas dificuldades. Pode falar sobre os maiores desafios de implantar projetos na Polkadot nos últimos anos?

Santi: Claro. A Polkadot é um sistema extremamente complexo; você precisa realmente entendê-la para que o projeto funcione bem. Essa complexidade vem justamente da sua flexibilidade — quanto mais flexível, mais complexo.

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

Jay: Pois é. Mas nos últimos anos, a experiência melhorou bastante. Pode contar como foi esse processo de mudança?

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

Embora ainda haja atualizações, hoje está bem mais estável e a compatibilidade entre versões melhorou muito. 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 na Polkadot.

Outro ponto foi a introdução do Coretime (embora ele também tenha certa complexidade), que realmente reduziu a barreira para os desenvolvedores. Facilitou as tentativas e diminuiu bastante o obstáculo de entrada na Polkadot. Acho que devemos aproveitar ao máximo isso.

Por que hoje os projetos escolhem implantar na 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 na 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, devemos comunicar e divulgar mais sobre isso. Na minha visão, a Polkadot é atualmente a única blockchain projetada desde o início para suportar Rollups de forma nativa. Ela oferece aos desenvolvedores uma infraestrutura que não existe em outros lugares.

• Por exemplo, a Polkadot oferece uma camada de disponibilidade de dados (data availability) muito robusta 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), algo que não existe em outros Rollups. A ausência desse recurso compromete a segurança do sistema.

• Em termos de desempenho, o Spamming já comprovou que o TPS dos Rollups da Polkadot é um dos mais altos do setor.

• Além disso, a escalabilidade elástica: a Polkadot é atualmente o único sistema 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, quase não precisa mudar nada para suportar esse tráfego.

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

Jay: Sim, você já me disse que a Polkadot foi projetada desde a base para os Rollups. Só não chamávamos de Rollup naquela época.

Santi: Exatamente. E tem outro ponto que muitas vezes ignoramos: a segurança compartilhada. Olhando para a história do blockchain: primeiro veio o bitcoin, depois o Ethereum. Depois, surgiram várias “novas Ethereums”, dizendo que eram melhores por causa de características A, B, C. Mas o problema é que garantir a segurança de uma nova rede é muito difícil. É preciso um conjunto de validadores grande e forte, o que não é fácil de conseguir.

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

Como surgiu a ideia do PDP?

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

Santi: Na verdade, essa ideia já vinha sendo amadurecida há algum 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. A ideia já estava no ar há tempos, e o setor já tinha algumas soluções semelhantes. No ecossistema Ethereum, por exemplo, existem o Conduit e o Gelato; na Polkadot, já houve o Tanssi, mas depois eles migraram para o Ethereum, com uma abordagem parecida.

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

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

Jay: Para quem exatamente o PDP é direcionado? Lembro que, no início da Polkadot, alguns projetos já começavam fazendo Rollup, mas na verdade um contrato inteligente 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. Ainda hoje vemos projetos que poderiam funcionar como contratos. Mas, às vezes, os desenvolvedores querem independência, não querem depender da infraestrutura de outra rede; outras vezes, preveem uma demanda muito alta de throughput no futuro, então preferem já começar como Rollup. Motivos como esses levam à necessidade de uma rede própria ou de mais independência na infraestrutura.

Por exemplo, o Omnipool da Hydration: podemos discutir se poderia ser apenas um contrato, mas acho que não, faz sentido ser uma rede. Por outro lado, veja o Uniswap no Ethereum: começou como contrato, depois criou sua própria rede, mas será que realmente precisa de uma? 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 escolham por si mesmos. E, seja para Rollup ou contrato, deve ser fácil experimentar e testar.

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

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

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

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

Por exemplo, ao construir um Rollup no Pop CLI, você pode conectá-lo diretamente ao PDP para fazer a implantação — foi assim que desenhamos e implementamos. Assim, o desenvolvedor pode usar o CLI para todo o processo, como o Heroku ou Vercel no Web2, ambos com seus próprios CLIs. Se preferir, pode usar só o CLI; ou pode optar por uma interface gráfica. As duas opções estão disponíveis.

Jay: Ou seja, além de construir com templates, também pode usar o Pop CLI e depois 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, mas se surgirem dúvidas importantes, estaremos ao lado para ajudar. Claro, se alguém quiser experimentar sozinho, também pode, 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, ideal para rodar uma rede com EVM.

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

Santi: Exato. Também há templates sem contratos inteligentes. Por exemplo, se alguém quiser criar uma rede apenas para custódia de 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: Os templates permitem adicionar novos Pallets conforme a necessidade?

Santi: No início, não. A ideia é começar com um 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 nossas prioridades atuais. Agora estamos usando uma ferramenta criada pela equipe Puppet, que compara o runtime que você vai atualizar com o já implantado, gerando um relatório sobre o que mudou, o que pode impactar os desenvolvedores e o que precisa de atenção.

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

Santi: Sim, terminamos essa semana. Assim, você recebe um relatório de upgrade do runtime para garantir que o que vai ser enviado está de acordo com o esperado. Queremos adicionar ainda uma função: simular alguns blocos em segundo plano para testar o novo runtime. Se tudo estiver certo, avisamos “pode lançar”; se houver problemas, avisamos “os testes falharam, melhor revisar”. Isso evita erros nas atualizações. Acreditamos que um dos diferenciais da Polkadot é suportar upgrades flexíveis do runtime, permitindo iteração rápida para encontrar o product-market fit.

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

Santi: Sim, aqui há uma sobreposição. Pode-se entender que construção começa com o template; implantação envolve a infraestrutura de base. Antes, era preciso ter uma equipe DevOps para montar nós collator e fazer toda a 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 disso para você.

Jay: Quem faz isso hoje?

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

Lançamos também o conceito de BDU (Basic Deployment Unit, Unidade Básica de Implantação): sempre que você quiser implantar um Rollup em rede de produção, fornecemos uma infraestrutura padronizada, incluindo três nós collator (um deles como endpoint RPC) e um indexador.

Estamos colaborando com a Subscan, que tem uma solução open source que planejamos integrar ao PDP. Assim, além do indexador, você terá um explorador de blocos. Antes, as equipes gastavam muito tempo montando isso, agora resolvemos tudo de forma integrada — um ótimo design.

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

Santi: Isso é implantação.

Jay: Entendi. Então, nesse ponto, 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! O Access é o destaque da Polkadot, e é aí que ela oferece valor único para as equipes de Rollup. Construção e implantação envolvem runtime e infraestrutura, que todos conseguem explorar rapidamente, mas usar as características da Polkadot faz a diferença. Por exemplo, o Coretime faz parte do Access: o PDP compra Coretime antecipadamente, assim, quando o desenvolvedor implanta o Rollup, já pode usá-lo imediatamente, sem esperar 28 dias para começar a produzir blocos — uma grande melhoria na 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 fração do core. Se quiser testar gastando pouco, pode usar só uma parte.

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

Santi: Já está disponível no PDP. Atualmente, funciona 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, permitindo testar quase sem custos. Se der certo, você pode migrar para um core completo e ter blocos a cada seis segundos — tudo pelo PDP. Ainda precisamos resolver como usar a Polkadot de forma eficiente na integração. O Polkadot Hub, um módulo funcional importante, será lançado em breve e estamos animados com isso.