Portale di distribuzione Polkadot: perché i progetti dovrebbero scegliere di essere distribuiti su Polkadot invece di diventare una L2?

In passato, distribuire un Rollup su Polkadot non è mai stato un compito facile. Più un sistema è flessibile, più il processo di distribuzione tende a essere complesso: dall’aggiornamento dell’SDK, all’asta degli slot, fino alla governance e agli upgrade del runtime, ogni fase può rappresentare una sfida per il team.

Per cambiare questa situazione, Parity ha lanciato quest’anno il Polkadot Deployment Portal (PDP): un “punto di accesso unico” che va dalla costruzione, al deployment, fino all’integrazione. L’obiettivo è chiaro: abbassare la soglia d’ingresso, semplificare i processi e permettere a qualsiasi team di avviare e gestire rapidamente e stabilmente il proprio Rollup su Polkadot.

In questo articolo, Santi Balaguer, responsabile dello sviluppo prodotto di Parity, ci guiderà attraverso l’evoluzione dell’esperienza di deployment su Polkadot negli ultimi anni, analizzerà la filosofia di design dietro PDP e condividerà come questo strumento stia cambiando passo dopo passo il modo in cui si avviano i Rollup.

Esperienza di deployment su Polkadot: più flessibilità, più complessità

Jay: Benvenuto a Space Monkeys, oggi abbiamo invitato Santi Balaguer, responsabile dello sviluppo prodotto di Parity. Oggi parleremo di PDP, qual è il nome completo di PDP?

Santi: È Polkadot Deployment Portal — il portale di deployment di Polkadot.

Jay: Prima di iniziare a lavorare su PDP, di cosa ti sei occupato principalmente in questi quattro o cinque anni in Parity?

Santi: Ho sempre lavorato a stretto contatto con la comunità degli sviluppatori, aiutandoli principalmente ad avviare parachain e Rollup su Polkadot. Come hai detto, ero già in Parity quando le parachain non erano ancora state lanciate.

Jay: Tra i progetti con cui hai avuto a che fare spesso, quali sono quelli che conosciamo meglio?

Santi: In passato mi sono occupato del progetto Substrate Builders, che include molti progetti noti. Quello che mi ha colpito di più è stato il team Hydration. Ricordo ancora quando Jakub fece una demo, presentando l’idea di Omnipool e i problemi che Hydration voleva risolvere. Mostrò un meme classico “money printer goes brrrr” per spiegare perché volevano proporre una nuova soluzione. Ancora oggi scherzo spesso con Jakub su questo.

Jay: Ahah, fantastico. Sicuramente hai visto molti progetti avere successo su Polkadot, ma avrai anche sentito molte delle loro difficoltà. Puoi parlarci dei punti più critici nel deployment di progetti su Polkadot negli ultimi anni?

Santi: Certamente. Polkadot è un sistema molto complesso, bisogna davvero capirlo per far funzionare bene un progetto. Questa complessità deriva dalla sua flessibilità: più un sistema è flessibile, più è complesso.

All’inizio, per far girare una parachain su Polkadot, bisognava affrontare vari “aggiornamenti distruttivi” dell’SDK. All’epoca non esisteva ancora il Polkadot SDK, c’era solo Substrate, che era diverso da ora. Una volta sistemato l’ambiente di sviluppo, bisognava raccogliere voti nella comunità e partecipare all’asta degli slot. L’asta stessa era una sfida: serviva il supporto di molte persone e il risultato si sapeva solo all’ultimo momento. Anche vincendo, bisognava aspettare tre mesi prima che la parachain fosse effettivamente online. Inoltre, lo slot veniva affittato solo per due anni. Quindi bisognava impegnarsi sia sullo sviluppo tecnico che sulla mobilitazione della comunità per guadagnarsi un posto su Polkadot.

Jay: Già. Negli ultimi anni però l’esperienza è migliorata molto. Puoi parlarci di questo cambiamento?

Santi: Certo. Credo che Parity abbia fatto grandi sforzi, soprattutto nel ridurre gli aggiornamenti distruttivi del Polkadot SDK.

Anche se ci sono ancora aggiornamenti, ora è molto più stabile rispetto a prima e la compatibilità tra versioni è migliorata. Gli sviluppatori possono contare maggiormente sulla versione dell’SDK che usano. Alcune parachain usano ancora vecchie versioni di Substrate, ma funzionano comunque su Polkadot.

Un altro aspetto è l’introduzione di Coretime (anche se ha una certa complessità), che ha davvero abbassato la soglia per gli sviluppatori. Ora è più facile provare, la barriera d’ingresso su Polkadot è molto più bassa e credo che dovremmo sfruttare al massimo questa opportunità.

Perché oggi un progetto dovrebbe scegliere Polkadot invece di fare un L2 su Ethereum?

Jay: Anche se allora c’erano molte sfide, ora molte sono state risolte. Secondo te, perché oggi un progetto dovrebbe scegliere di distribuire su Polkadot? Perché non fare un L2 su Ethereum o lanciare una propria L1? Quali sono le ragioni?

Santi: È una domanda interessante. Credo che come comunità dovremmo comunicare e promuovere di più questi aspetti. Dal mio punto di vista, Polkadot è attualmente l’unica blockchain progettata fin dall’inizio per supportare nativamente i Rollup. Offre agli sviluppatori infrastrutture che altrove non esistono.

• Ad esempio, Polkadot offre un livello di data availability per i Rollup molto ampio, mentre su Ethereum L2 bisogna affidarsi a sistemi esterni o ai “blob” per risolvere questo problema.

• Un altro esempio è la messaggistica nativa tra parachain (cross-chain communication), che non esiste su altri Rollup. La mancanza di questa funzione riduce la sicurezza del sistema.

• Guardando alle performance, Spamming ha già dimostrato che il TPS dei Rollup su Polkadot è tra i migliori del settore.

• Inoltre, per quanto riguarda la scalabilità elastica, Polkadot è attualmente l’unico sistema che può espandere o ridurre l’infrastruttura in base alle esigenze. Ad esempio, se Mythical vuole lanciare un nuovo gioco e si aspetta che gli utenti aumentino di 10 volte nella prima settimana, può supportare subito questo traffico senza grandi modifiche.

Penso che nelle discussioni passate su “parachain e Rollup” non siamo riusciti a mettere Polkadot al centro della scena, perdendo un’opportunità. Ma non è troppo tardi, abbiamo ancora la possibilità di riportarlo in primo piano.

Jay: Già, mi avevi detto che Polkadot, fin dalla progettazione dell’architettura di base, era pensato per i Rollup. Solo che all’inizio non li chiamavamo Rollup.

Santi: Esatto, e c’è un altro aspetto che spesso trascuriamo: la sicurezza condivisa. Guardando allo sviluppo della blockchain: prima c’era bitcoin, poi Ethereum. Poi tutti hanno iniziato a lanciare nuovi “Ethereum”, dicendo che la loro chain era migliore perché aveva le caratteristiche A, B, C. Ma il problema è che garantire la sicurezza di una nuova chain è molto difficile. Serve un set di validatori grande e forte, e non è facile ottenerlo.

All’epoca Gavin pensò: perché non offrire la sicurezza come servizio, integrandola nel layer di base? Questa è la particolarità di Polkadot. Non solo offre sicurezza condivisa, ma permette anche una comunicazione efficiente tra questi Rollup, cosa in cui Polkadot eccelle.

Come è nata l’idea di PDP?

Jay: Fantastico. Se un Rollup vuole una data availability integrata (e su larga scala), senza dover mettere insieme soluzioni di altri progetti, vuole TPS e throughput elevati e comunicazione fluida con altri Rollup, allora Polkadot è davvero interessante. Ma prima di PDP, distribuire una parachain era comunque molto complesso e richiedeva tempo. Da dove è nata l’idea di creare PDP?

Santi: In realtà l’idea era nell’aria da un po’, anche se abbiamo iniziato a lavorarci davvero solo lo scorso novembre.

Il nostro team si è dedicato a tempo pieno al progetto da marzo/aprile di quest’anno e ora stiamo facendo grandi progressi, trasformando l’idea in realtà. Era un progetto pensato da tempo e nel settore esistono già soluzioni simili. Nell’ecosistema Ethereum ci sono Conduit e Gelato; su Polkadot c’era Tanssi, che poi si è spostato principalmente su Ethereum, con un approccio simile.

Abbiamo visto che su Polkadot mancava ancora una soluzione concreta, così abbiamo deciso di occuparcene direttamente, per assicurarci che il progetto andasse in porto. Dopotutto, conosciamo Polkadot in profondità e sappiamo come renderlo più accessibile agli sviluppatori: questo è l’obiettivo che PDP vuole raggiungere.

Non decidiamo per gli sviluppatori, ma offriamo guida e scelta

Jay: A chi si rivolge PDP? Ricordo che all’inizio su Polkadot c’era il problema che alcuni progetti partivano subito con un Rollup, ma in realtà sarebbe bastato uno smart contract. Secondo te, quali progetti hanno davvero bisogno di un proprio Rollup?

Santi: È una buona domanda, ma credo non ci sia una risposta fissa. Ancora oggi troviamo progetti per cui potrebbe avere senso essere solo un contratto. Ma a volte il team vuole indipendenza, non vuole dipendere dall’infrastruttura di altre chain; altre volte si aspettano un throughput molto elevato in futuro, quindi preferiscono partire subito con un Rollup. Questi e altri motivi portano a scegliere una propria chain o una maggiore indipendenza infrastrutturale.

Prendiamo ad esempio Omnipool di Hydration: si potrebbe discutere se basti un contratto, ma secondo me no, ha senso che sia una chain. Dall’altra parte, guardiamo Uniswap su Ethereum: è nato come contratto, poi ha creato la propria chain, ma ne ha davvero bisogno? Forse no, ma hanno le loro considerazioni commerciali.

Quindi non c’è una regola assoluta, è una scelta guidata sia dalla tecnologia che dal business. Per me la cosa più importante è: non dobbiamo decidere per gli sviluppatori, ma offrire guida e lasciare che scelgano. Che vogliano fare un Rollup o un contratto, devono poter provare e sperimentare facilmente.

Esperienza completa con PDP: dalla costruzione, al deployment, all’accesso, avviare un Rollup è così semplice

Jay: Bene, supponiamo che un team abbia deciso, sia di propria iniziativa che guidato da Magenta Labs o dal team BD. Alla fine decidono di distribuire un rollup su Polkadot. Cosa succede quando entrano in PDP? Qual è il processo di deployment attuale?

Santi: Nel design di PDP, abbiamo suddiviso il processo in tre fasi principali: Build (costruzione) — Deploy (distribuzione) — Access (accesso), tutte collegate tra loro.

Nella fase di “costruzione”, la domanda chiave è “da dove inizio?”. La nostra idea è: il modo migliore è tramite i runtime template. Attualmente OpenZeppelin sta sviluppando template correlati, anche i team Pop CLI e ROG stanno lavorando in questa direzione. Pop CLI è fondamentalmente uno strumento che puoi usare sul tuo computer per scrivere Rollup. Collaboriamo con loro per integrare Pop CLI con le altre due fasi di PDP (deploy e access).

Ad esempio, una volta costruito un Rollup su Pop CLI, puoi collegarlo direttamente a PDP per distribuirlo: è così che lo abbiamo progettato e realizzato. Così gli sviluppatori possono completare l’intero processo tramite CLI, proprio come Heroku o Vercel nel Web2, che hanno i loro CLI. Se preferisci questo metodo, puoi usare direttamente la CLI; ovviamente puoi anche seguire tutto tramite interfaccia grafica. Entrambi i metodi vanno bene.

Jay: Quindi, oltre a costruire tramite template, si può usare Pop CLI e poi distribuire. PDP aiuta gli sviluppatori a fare delle scelte o è solo uno strumento che lascia tutto al team?

Santi: Entrambe le cose. Vogliamo che PDP sia uno strumento self-service, che gli sviluppatori possano usare autonomamente. Ma se incontrano problemi chiave, ovviamente li supporteremo, assicurandoci che ricevano l’aiuto necessario. Certo, se qualcuno vuole provare da solo, va benissimo ahah.

Jay: Interessante. Puoi fare qualche esempio concreto di template? Quali ti piacciono di più?

Santi: Ad esempio, il team ROG ha un template pronto chiamato Pilot Revive, che puoi usare direttamente per avviare. OpenZeppelin ha il template Frontier: se vuoi una chain con funzionalità EVM, puoi usarlo subito.

Jay: Molto interessante, quindi ci sono varie opzioni legate agli smart contract.

Santi: Esatto. Ci sono anche template senza smart contract. Ad esempio, se qualcuno vuole solo una chain per la custodia di asset, soprattutto per progetti legati agli asset del mondo reale (RWA), c’è un template dedicato. Insomma, all’inizio ci sono molte opzioni tra cui scegliere, poi si può sempre espandere.

Jay: Si possono aggiungere nuovi Pallet ai template secondo le proprie esigenze?

Santi: All’inizio no. L’idea è partire dal template, poi guidiamo passo dopo passo verso l’upgrade del runtime. Vogliamo che il team trovi gradualmente il product-market fit. Questo design è interessante ed è una delle funzionalità su cui ci stiamo concentrando: ora stiamo usando uno strumento molto interessante sviluppato dal team Puppet, che confronta il runtime che stai per aggiornare con quello già distribuito, generando un report che ti dice cosa è cambiato, cosa può influenzare gli sviluppatori e a cosa prestare attenzione.

Jay: Sì, ho visto che avete appena integrato questa funzione, fantastico.

Santi: Sì, l’abbiamo completata proprio questa settimana. Così ricevi un report sull’upgrade del runtime, per assicurarti che ciò che stai per distribuire sia conforme alle aspettative. In futuro vogliamo aggiungere una funzione che simula in background alcuni blocchi con il nuovo runtime: se tutto va bene, ti diciamo “puoi andare online”; se ci sono problemi, ti avvisiamo “il test non è passato, meglio ricontrollare”. Così si evitano errori durante l’upgrade. Crediamo che uno dei punti di forza di Polkadot sia proprio la possibilità di upgrade flessibili del runtime, che permettono ai team di iterare rapidamente e trovare il product-market fit.

Jay: Aspetta, quindi questa parte fa già parte della fase “deploy”? Quello di cui abbiamo parlato, dalla costruzione al runtime, è già deployment?

Santi: Sì, qui c’è un po’ di sovrapposizione. Si può dire che la costruzione parte dal template; il deployment riguarda l’infrastruttura di base. Prima serviva un team DevOps per configurare i nodi collator e gestire l’operatività, ora all’inizio non serve preoccuparsene. Se il progetto cresce e ha risorse, puoi sempre creare un tuo team di gestione, e noi ti aiuteremo nella migrazione. Ma all’inizio, ci occupiamo noi di tutto.

Jay: Chi si occupa di questo ora?

Santi: Attualmente è Parity a fornire il servizio. In futuro però permetteremo agli sviluppatori di scegliere su quale cloud deployare, o anche su IBP (infrastructure provider). L’astrazione di questo livello richiede tempo, quindi per ora, per garantire l’esperienza, usiamo l’infrastruttura di Parity, ma in futuro offriremo più opzioni.

Abbiamo anche introdotto un concetto chiamato BDU (Basic Deployment Unit, unità di deployment di base): ogni volta che vuoi distribuire un Rollup su una rete di produzione, ti forniamo un’infrastruttura standardizzata con tre nodi collator, uno dei quali funge anche da endpoint RPC, più un indexer.

Stiamo collaborando con Subscan, che ha una soluzione open source che vogliamo integrare in PDP. Così avrai non solo l’indexer, ma anche un block explorer: prima serviva molto tempo per configurare tutto questo, ora lo facciamo noi in un’unica soluzione, un ottimo design.

Jay: Wow, sembra fantastico. Questa parte fa parte della costruzione?

Santi: Questa è la distribuzione.

Jay: Capito, quindi a questo punto il Rollup è già in funzione? Sta già producendo blocchi? Il team può già fare upgrade del runtime per iterare e trovare il product-market fit? E poi c’è l’ultima fase, “Access”, giusto? Cos’è?

Santi: Esatto! Access è il punto di forza di Polkadot, ed è proprio qui che Polkadot offre valore unico ai team Rollup. La costruzione e la distribuzione riguardano runtime e infrastruttura, che tutti possono imparare rapidamente, ma usare davvero le caratteristiche di Polkadot fa la differenza. Ad esempio, Coretime fa parte di Access: PDP acquista Coretime in anticipo, così quando uno sviluppatore vuole distribuire un Rollup, può usarlo subito senza aspettare 28 giorni per iniziare a produrre blocchi, un enorme miglioramento per l’esperienza utente.

Jay: Se voglio distribuire, devo comprare Coretime su PDP?

Santi: Lo compriamo noi per te, poi ti addebitiamo il costo. In realtà, offriamo diverse opzioni per Coretime. Se vuoi partire subito al massimo, puoi usare un core completo. Ma offriamo anche “core slice”, cioè una parte del core: se vuoi solo provare, spendere poco e vedere come va, puoi usare solo una piccola parte del core.

Jay: Questa funzione è già disponibile?

Santi: È già disponibile su PDP. Attualmente è attiva sulle reti Westend e Paseo. Paseo ha appena lanciato il core slice, mentre su Westend puoi scambiare direttamente una parte del core: il tempo di produzione dei blocchi sarà più lungo, ma la soglia d’ingresso è molto più bassa, puoi testare a costi minimi. Se va bene, puoi passare a un core completo e avere blocchi ogni sei secondi, tutto su PDP. Tuttavia, il meccanismo di accesso deve ancora essere ottimizzato per sfruttare al meglio Polkadot. Polkadot Hub, come modulo funzionale chiave, sta per essere lanciato e siamo molto fiduciosi.