Portal de implementación de Polkadot: ¿Por qué los proyectos eligen desplegarse en Polkadot en lugar de convertirse en una L2?

En el pasado, desplegar un Rollup en Polkadot nunca fue una tarea sencilla. Porque cuanto más flexible es un sistema, normalmente también significa que el proceso de despliegue es más complejo: desde la actualización del SDK, pasando por la subasta de slots, hasta la gobernanza y la actualización del runtime, cada etapa puede convertirse en un desafío para el equipo.

Para cambiar esta situación, Parity lanzó este año el Polkadot Deployment Portal (PDP), una “puerta de entrada integral” que abarca desde la construcción, el despliegue hasta la integración. Su objetivo es claro: bajar la barrera de entrada, simplificar los procesos y permitir que cualquier equipo pueda lanzar y operar su propio Rollup en Polkadot de manera rápida y estable.

En este artículo, Santi Balaguer, responsable de desarrollo de producto en Parity, nos llevará a repasar la evolución de la experiencia de despliegue en Polkadot en los últimos años, analizará la filosofía de diseño detrás de PDP y compartirá cómo esta herramienta está cambiando paso a paso la forma en que se lanzan los Rollups.

La experiencia de desplegar en Polkadot: cuanto más flexible es el sistema, más complejo suele ser

Jay: Bienvenido a Space Monkeys, hoy invitamos a Santi Balaguer, responsable de desarrollo de producto en Parity. Hoy vamos a hablar de PDP, ¿cómo es el nombre completo de PDP?

Santi: Es Polkadot Deployment Portal — el portal de despliegue de Polkadot.

Jay: Antes de empezar con PDP, ¿en qué has estado trabajando estos cuatro o cinco años en Parity?

Santi: Siempre he estado en contacto estrecho con la comunidad de desarrolladores, principalmente ayudándolos a lanzar parachains y Rollups en Polkadot. Como decís, estoy en Parity desde antes de que las parachains estuvieran en línea.

Jay: ¿Cuáles de los proyectos con los que has trabajado son los más conocidos para nosotros?

Santi: Antes estaba a cargo del proyecto Substrate Builders, que incluye muchos proyectos conocidos. El que más recuerdo es el equipo de Hydration. Todavía me acuerdo cuando Jakub hizo una demo, presentando su idea de Omnipool y los problemas que Hydration quería resolver. Puso un meme clásico de “money printer goes brrrr” para explicar por qué necesitaban una nueva solución. Hasta hoy sigo bromeando con Jakub sobre eso.

Jay: Jaja, genial. Seguro viste muchos proyectos tener éxito en Polkadot, y también escuchaste muchas de sus dificultades. ¿Podés contarnos cuáles fueron los mayores dolores de cabeza al desplegar proyectos en Polkadot en los últimos años?

Santi: Por supuesto. Polkadot es en sí un sistema muy complejo, tenés que entenderlo realmente para que tu proyecto funcione bien. Esta complejidad viene de su flexibilidad: cuanto más flexible es el sistema, más complejo suele ser.

En los primeros tiempos, para correr una parachain en Polkadot, primero tenías que lidiar con las “actualizaciones disruptivas” del SDK. En ese entonces no existía Polkadot SDK, solo Substrate, que no era como ahora. Una vez que resolvías el entorno de desarrollo, tenías que buscar apoyo en la comunidad y participar en la subasta de slots. La subasta en sí era un gran desafío, necesitabas suficiente apoyo y el resultado se conocía recién al final. Incluso si ganabas, tenías que esperar tres meses para que la parachain estuviera en línea. Además, el slot solo se alquilaba por dos años. Así que tenías que esforzarte tanto en el desarrollo técnico como en la movilización de la comunidad para ganar un lugar en Polkadot.

Jay: Sí. En los últimos años la experiencia mejoró bastante. ¿Podés contarnos cómo fue ese proceso de cambio?

Santi: Claro. Creo que Parity hizo un gran esfuerzo, especialmente en reducir las actualizaciones disruptivas del Polkadot SDK.

Si bien todavía hay actualizaciones, ahora es mucho más estable y la compatibilidad entre versiones es mucho mejor. Ahora los desarrolladores pueden confiar en la versión del SDK que usan. Incluso hay parachains que siguen usando versiones viejas de Substrate y siguen funcionando bien en Polkadot.

Además, la introducción de Cortime (aunque también tiene cierta complejidad) realmente bajó la barrera para los desarrolladores. Hace que sea más fácil probar y reduce mucho la barrera de entrada a Polkadot. Creo que deberíamos aprovechar esto al máximo.

¿Por qué ahora los proyectos eligen desplegar en Polkadot y no hacer un L2 en Ethereum?

Jay: Aunque antes había muchos desafíos, ahora ya se resolvieron varios. ¿Por qué creés que hoy un proyecto elegiría desplegar en Polkadot? ¿Por qué no hacer un L2 en Ethereum o lanzar su propio L1? ¿Cuál es la razón?

Santi: Es una pregunta muy interesante. Primero, creo que como comunidad deberíamos comunicar y difundir más sobre esto. Según mi entendimiento y opinión, Polkadot es la única blockchain que desde el principio fue diseñada para soportar Rollups de forma nativa. Ofrece a los desarrolladores infraestructura que no existe en otros lugares.

• Por ejemplo, Polkadot ofrece una capa de disponibilidad de datos (data availability) muy grande para los Rollups, mientras que en un L2 de Ethereum dependés de sistemas externos o “blobs” para resolverlo.

• Otro ejemplo es la mensajería nativa entre parachains (comunicación cross-chain), que no existe en otros Rollups. La falta de esta función reduce la seguridad del sistema.

• En cuanto al rendimiento, Spamming ya demostró que el nivel de TPS de los Rollups en Polkadot es de los más altos de la industria.

• Y sobre la escalabilidad elástica, Polkadot es el único sistema que puede expandir o reducir la infraestructura según la demanda. Por ejemplo, si Mythical lanza un nuevo juego y espera que los usuarios aumenten 10 veces en la primera semana, casi no tienen que cambiar nada para soportar ese tráfico.

Creo que en las discusiones pasadas sobre “parachains y Rollups” no logramos que Polkadot fuera el protagonista, perdimos una oportunidad. Pero todavía estamos a tiempo de ponerlo en el centro del escenario.

Jay: Sí, me dijiste antes que Polkadot, desde su diseño de arquitectura, estaba pensado para Rollups. Solo que al principio no lo llamábamos Rollup.

Santi: Exacto, y hay algo que a menudo pasamos por alto: la seguridad compartida. Si miramos la historia del blockchain: primero fue bitcoin, luego Ethereum. Después empezaron a salir nuevos “Ethereums”, diciendo “mi cadena es mejor porque tiene A, B, C”. Pero el problema es que garantizar la seguridad de una nueva cadena es muy difícil. Necesitás un conjunto de validadores grande y fuerte, y eso no es fácil.

En ese momento Gavin pensó: ¿por qué no ofrezco la seguridad como un servicio, incorporada en la capa base? Esa es la particularidad de Polkadot. No solo ofrece seguridad compartida, sino que también permite una comunicación eficiente entre estos Rollups, algo en lo que Polkadot es especialmente bueno.

¿Cómo surgió la idea de PDP?

Jay: Genial. Si un Rollup quiere disponibilidad de datos incorporada (y a gran escala), sin depender de otros proyectos, además de alto TPS y throughput, y comunicación fluida con otros Rollups, entonces Polkadot es realmente atractivo. Pero antes de PDP, desplegar una parachain seguía siendo muy complejo y llevaba mucho tiempo. ¿Por qué surgió la idea de PDP?

Santi: En realidad, la idea se venía gestando hace tiempo, aunque empezamos a trabajar en serio en noviembre del año pasado.

Después, desde marzo o abril de este año, el equipo se dedicó de lleno al proyecto, y avanzamos muy rápido, convirtiendo la idea en realidad paso a paso. Esto se venía pensando hace mucho, y ya había soluciones similares en la industria. Por ejemplo, en el ecosistema de Ethereum están Conduit y Gelato; en Polkadot antes estaba Tanssi, aunque después se enfocaron en Ethereum, con una idea parecida.

Vimos que en Polkadot no se concretaba nada, así que decidimos hacerlo nosotros mismos para asegurarnos de que saliera bien. Al fin y al cabo, entendemos Polkadot en profundidad y sabemos cómo facilitarle a los desarrolladores el despliegue de proyectos. Ese es el objetivo que PDP quiere resolver.

No tomamos decisiones por los desarrolladores, sino que ofrecemos guía y opciones

Jay: ¿A quién está dirigido PDP? Recuerdo que al principio en Polkadot había un problema: algunos proyectos empezaban haciendo Rollup, pero en realidad con un smart contract alcanzaba. ¿Qué tipo de proyectos realmente necesitan su propio Rollup?

Santi: Es una buena pregunta, pero creo que no hay una respuesta fija. Todavía hoy vemos proyectos que podrían funcionar como contrato, pero a veces el equipo necesita independencia y no quiere depender de la infraestructura de otra cadena; otras veces esperan un throughput muy alto en el futuro, así que prefieren hacer un Rollup desde el principio. Razones como estas hacen que necesiten su propia cadena o más independencia en la infraestructura.

Por ejemplo, el Omnipool de Hydration: podríamos discutir si podría ser solo un contrato, pero creo que no, que tiene sentido que sea una cadena. Por otro lado, mirá Uniswap en Ethereum: empezó como contrato y después hizo su propia cadena, pero ¿realmente la necesita? Tal vez no, pero tienen sus propias razones comerciales.

Así que no hay absolutos, es una combinación de factores técnicos y comerciales. Para mí, lo más importante es: no tomar decisiones por los desarrolladores, sino guiarlos y dejar que elijan. Y tanto si quieren hacer Rollup como contrato, deberían poder probar y experimentar fácilmente.

Experiencia completa de PDP: desde construir, desplegar hasta acceder, lanzar un Rollup es así de simple

Jay: Bien, supongamos que un equipo ya decidió, ya sea por sí mismo o guiado por Magenta Labs o el equipo de BD. Finalmente deciden desplegar un Rollup en Polkadot. ¿Qué experiencia tendrán al entrar a PDP? ¿Cómo es el proceso de despliegue ahora?

Santi: En el diseño de PDP, dividimos el proceso en tres etapas principales: Build (construir), Deploy (desplegar) y Access (acceder), que están interconectadas.

En la etapa de “construcción”, la pregunta clave es “¿cómo empiezo?”. Nuestra idea es: la mejor forma es a través de plantillas de runtime (runtime templates). Actualmente OpenZeppelin está desarrollando plantillas, y los equipos de Pop CLI y ROG también están trabajando en esto. Pop CLI es básicamente una herramienta que podés usar en tu computadora para escribir Rollups. Colaboramos con ellos para integrar Pop CLI con las otras dos etapas de PDP (despliegue y acceso).

Por ejemplo, si construís un Rollup en Pop CLI, podés conectarlo directamente a PDP y desplegarlo. Así lo diseñamos e implementamos. De esta manera, el desarrollador puede hacer todo el proceso por CLI, como en Heroku o Vercel en Web2, que también tienen su CLI. Si te gusta esa forma, podés usar CLI; si preferís la interfaz gráfica, también podés. Ambas opciones están disponibles.

Jay: O sea, además de construir con plantillas, también podés usar Pop CLI y luego desplegar. ¿PDP ayuda al desarrollador a tomar decisiones o es solo una herramienta y el equipo tiene que operar todo?

Santi: Ambas cosas. Queremos que PDP sea una herramienta de autoservicio para que los desarrolladores la usen por sí mismos. Pero si surgen problemas clave, por supuesto vamos a estar ahí para ayudar. Y si alguien quiere probar solo, también está perfecto, jaja.

Jay: Está bueno. ¿Podés dar algunos ejemplos concretos de plantillas? ¿Cuáles te gustan más?

Santi: Por ejemplo, el equipo de ROG tiene una plantilla lista llamada Pilot Revive, que podés usar directamente para lanzar. OpenZeppelin tiene la plantilla Frontier, que sirve si querés correr una cadena con funcionalidad EVM.

Jay: Muy bueno, son varias opciones relacionadas con smart contracts.

Santi: Exacto. También hay plantillas sin smart contracts. Por ejemplo, si alguien solo quiere hacer una cadena de custodia de activos, especialmente para proyectos de activos del mundo real (RWA), también hay plantillas para eso. En resumen, al principio hay varias opciones y después podés expandir sobre esa base.

Jay: ¿Se pueden agregar nuevos Pallets a las plantillas según la necesidad?

Santi: Al principio no. La idea es que empieces con una plantilla y después te guiamos paso a paso para hacer upgrades del runtime. Queremos que así el equipo encuentre el product-market fit. Este diseño es interesante y es una de las funciones en las que más trabajamos ahora. Estamos usando una herramienta muy interesante del equipo Puppet, que compara el runtime que vas a actualizar con el que ya está desplegado, y genera un informe que te dice qué cambió, qué puede afectar a los desarrolladores y qué hay que tener en cuenta.

Jay: Sí, vi que acaban de integrar eso, genial.

Santi: Sí, lo terminamos esta semana. Así recibís un informe de upgrade del runtime, asegurando que lo que vas a subir coincide con lo esperado. Próximamente queremos agregar una función para simular en segundo plano algunos bloques con el nuevo runtime. Si todo anda bien, te avisamos que podés lanzar; si hay problemas, te decimos “no pasó nuestras pruebas, mejor revisá”. Así evitamos errores en los upgrades. Creemos que una de las ventajas de Polkadot es soportar upgrades flexibles del runtime, y los equipos pueden aprovechar esto para iterar rápido y encontrar el product-market fit.

Jay: Esperá, ¿esta parte ya cuenta como la etapa de “despliegue”? ¿Lo que hablamos de construir y runtime es parte del despliegue?

Santi: Sí, acá hay un poco de superposición. Podés entenderlo así: construir es más empezar desde la plantilla; desplegar implica la infraestructura base. Antes necesitabas tu propio equipo DevOps para montar nodos collator y hacer mantenimiento, pero ahora al principio no hace falta. Si el proyecto crece y tenés fondos y recursos, podés armar tu propio equipo de operaciones y te ayudamos a migrar. Pero al principio, nosotros nos encargamos de eso.

Jay: ¿Quién se encarga de eso ahora?

Santi: Actualmente lo provee Parity. Pero en el futuro dejaremos que los desarrolladores elijan en qué nube desplegar, incluso puede ser un IBP (proveedor de infraestructura), pero abstraer esa capa lleva tiempo, así que ahora usamos la infraestructura de Parity para asegurar la experiencia, pero después habrá más opciones.

También lanzamos un concepto llamado BDU (Basic Deployment Unit, unidad básica de despliegue): si querés desplegar un Rollup en la red de producción, te montamos una infraestructura estándar con tres nodos collator, uno de los cuales sirve como endpoint RPC, y además te damos un indexador.

Ahora estamos colaborando con Subscan, que tiene una solución open source, y planeamos integrarla en PDP. Así no solo tenés un indexador, sino también un explorador de bloques. Antes el equipo tenía que montar todo esto, ahora lo resolvemos en un solo paso, lo cual está muy bueno.

Jay: Wow, suena genial. ¿Esto cuenta como construcción?

Santi: Esto es despliegue.

Jay: Entiendo, ¿en este punto el Rollup ya está funcionando? ¿Ya produce bloques? ¿El equipo puede hacer upgrades del runtime para iterar y encontrar el product-market fit? ¿Y después viene la última etapa, “Access”, verdad? ¿Qué es eso?

Santi: ¡Exacto! Access es el punto fuerte de Polkadot, y creo que es donde realmente aporta valor único a los equipos de Rollup. Construir y desplegar tiene que ver con el runtime y la infraestructura, que cualquiera puede aprender rápido, pero el verdadero diferencial de Polkadot está en aprovechar sus características. Por ejemplo, Coretime es parte de Access: PDP compra Coretime por adelantado, así que cuando el desarrollador quiere desplegar un Rollup, puede usarlo de inmediato, sin esperar 28 días para empezar a producir bloques. Esto mejora muchísimo la experiencia de usuario.

Jay: Si quiero desplegar, ¿tengo que comprar Coretime en PDP?

Santi: Nosotros lo compramos por vos y después te cobramos. De hecho, ofrecemos diferentes opciones de Coretime. Si querés ir a fondo desde el principio, podés usar un core completo. Pero también ofrecemos “core fragmentado”, o sea, una parte del core. Si solo querés probar sin gastar mucho, podés usar una pequeña parte del core.

Jay: ¿Esta función ya está disponible?

Santi: Ya se puede usar en PDP. Actualmente está funcionando en las redes Westend y Paseo. Paseo acaba de lanzar el core fragmentado, y en Westend podés negociar una parte del core. La desventaja es que el tiempo de bloque es más largo, pero la ventaja es que la barrera de entrada es mucho más baja y podés probar a bajo costo. Si todo sale bien, podés pasar a un core completo y tener bloques cada seis segundos, todo desde PDP. Pero el mecanismo de integración aún requiere resolver cómo aprovechar Polkadot de manera eficiente. Actualmente, Polkadot Hub está por lanzarse como un módulo funcional importante, y tenemos muchas expectativas al respecto.