Il mese scorso, un altro gruppo di sviluppatori e studenti ha completato l'apprendimento di Web3 presso la Polkadot Blockchain Academy (PBA) a Lucerna, in Svizzera! Gavin è andato personalmente a partecipare alla cerimonia di laurea e ha portato benedizioni e visioni a tutti il giorno della laurea! Allo stesso tempo, diversi team di implementazione del protocollo JAM hanno anche condiviso i loro viaggi in JAM e una profonda comprensione del protocollo JAM con i laureati in loco!

Che tu sia uno sviluppatore che vuole unirsi a JAM o un utente comune che crede nel futuro di JAM, vale la pena leggere e studiare questo articolo!

A causa della lunghezza del contenuto, PolkaWorld lo pubblicherà in due parti. Questo è il primo articolo, che riguarda principalmente i seguenti contenuti:

  • Presentazione del team di implementazione JAM

  • Perché partecipare allo sviluppo del protocollo JAM?

  • Stato di sviluppo di JAM: 38 team, 15 linguaggi, nessun capo, nessun ordine

  • Cosa stanno facendo questi 38 team di sviluppo? Quali sono i loro obiettivi a breve e medio termine?

  • Come sarà il percorso di migrazione da Polkadot a JAM?

  • Se volete davvero realizzare Web3, l'unica scelta ora è Polkadot e JAM

Continua a leggere per scoprire tutti i dettagli!

Presentazione del team JAM

Jay: Benvenuti all'evento dell'Academy a Lucerna! Oggi c'è un gruppo di pubblico fantastico. Ora entriamo in una parte molto importante dell'Academy: la discussione approfondita del progetto JAM, oggi abbiamo invitato un gruppo di relatori molto eccitanti, ora lasciamo il tempo a Kian Paimani, lasciategli presentare gli ospiti e iniziare la discussione, rimanete sintonizzati!

Kian: Grazie a tutti! Per gli amici che guardano la trasmissione in diretta in classe, la maggior parte degli ospiti dovrebbe già conoscerli. Ma per il pubblico online, facciamo una breve auto-presentazione e chiediamo a ogni ospite di dire in quale team si trova e come è coinvolto nel progetto JAM. Lascerò prima il microfono a Tomek.

Kian

Tomek: Ciao a tutti, sono Tomek e vengo da Fluffy Labs. Circa otto mesi fa, abbiamo deciso di implementare il protocollo JAM in TypeScript. Questa implementazione si chiama Typeberry. Durante lo sviluppo, avevamo anche l'obiettivo di migliorare l'esperienza di sviluppo di altri team JAM, quindi stiamo anche costruendo attivamente una toolchain relativa a JAM.

Kian: Perché si chiama Fluffy Labs?

Tomek: Allora volevo trovare un nome divertente, perché molte aziende amano nominare con concetti matematici seri, Fluffy Labs può anche ricordare Fluffy Labrador (Labrador peloso), in realtà abbiamo disegnato un cane sul nostro adesivo, che è quello di riflettere l'atmosfera rilassata e divertente.

Daniel: Ciao a tutti, sono Daniel, lavoro nel team jamixir e implementiamo JAM con il linguaggio Elixir. Nel nostro team ci sono solo io e Luke. Ho iniziato a farlo circa un anno fa, dopo il corso PBA. Ho partecipato al corso PBA a Hong Kong. Per capire meglio JAM, ho imparato e fatto, e ho anche condiviso alcuni contenuti relativi a JAM su Twitter, sperando di far conoscere il progetto a più persone. Naturalmente, sappiamo che c'è ancora molta strada da fare prima che JAM possa essere veramente messo in produzione, ma questa fase è molto interessante.

Maciej: Ciao a tutti, sono Maciej, nel team Graymatter. Stiamo anche costruendo l'implementazione JAM con Elixir, ma il nostro team è un po' più grande, ci sono quattro persone, ma tutti lo fanno part-time. Vorrei anche condividere un punto di vista con tutti: partecipare allo sviluppo di JAM non deve necessariamente essere un impegno a tempo pieno, puoi partecipare nel tuo tempo libero, ad esempio facendo lo sviluppo di client leggeri o facendo strumenti correlati, adatti a vari tipi di persone per partecipare.

Siamo anche consapevoli del fatto che, poiché lo facciamo part-time, la velocità non sarà paragonabile a quella dei team a tempo pieno, ma speriamo di andare il più lontano possibile e collaboriamo attivamente con altri team, ad esempio condividendo strumenti, set di test e così via, con l'obiettivo di rendere l'intero protocollo più robusto. Per quanto riguarda il motivo per cui mi sono unito a JAM, è perché credo che sarà il futuro di Polkadot. JAM può fornire un livello di astrazione superiore, aprendo nuove possibilità che non erano possibili in passato.

Alistair: Ciao a tutti, sono Alistair e attualmente lavoro come Chief Scientist presso la Web3 Foundation. Il mio compito principale è supportare la progettazione di JAM dal punto di vista teorico.

Kian: Ok, grazie a tutti! Aggiungo che sono Kian, sono anche nel team Graymatter e lavoro come project manager, e di solito partecipo anche allo sviluppo di JAM part-time. La mia motivazione principale è quella di comprendere a fondo il protocollo partecipando alle prime due pietre miliari, in modo da poter gettare le basi per avere più opportunità di partecipazione e contributo dopo che JAM sarà online nell'ambiente di produzione formale in futuro.

Perché unirsi allo sviluppo del protocollo JAM?

Successivamente, vorrei chiedere a tutti di parlare un po' più approfonditamente del motivo per cui avete scelto di unirvi a JAM, quali sono le vostre motivazioni specifiche? Perché pensate che valga la pena investirci?

Tomek: Per me e il mio team, all'inizio stavamo pensando di farlo part-time, puramente perché pensavamo che fosse molto interessante. In precedenza lavoravo a Parity, ho lavorato a Polkadot, dopo un periodo di riposo, ho scoperto che il progetto JAM era un buon modo per tornare indietro, posso usare la conoscenza e l'esperienza accumulate in passato per tornare nell'ecosistema, dopo aver condiviso questa idea con alcuni amici, anche loro erano molto interessati, quindi in seguito abbiamo deciso di impegnarci più a tempo pieno, dovrebbe essere così.

Maciej: La collaborazione con Kian non è casuale, ma è dovuta alla nostra forte convergenza di motivazioni. Ritengo inoltre che sia fondamentale studiare il protocollo JAM perché avrà sicuramente un'importanza significativa in futuro. Anche se attualmente mi occupo di altro, sono consapevole della lungimiranza di questa tecnologia. Spesso ricevo domande su JAM da studenti della PBA o da altri sviluppatori e, in quanto persona ancora coinvolta nello sviluppo di Polkadot, mi sento responsabile di comprendere e rispondere a queste domande. Il modo migliore per farlo è sporcarsi le mani, costruire e leggere il Gray Paper con tutti i suoi dettagli di progettazione. Naturalmente, credo anche che JAM possa portare nuove funzionalità impossibili da realizzare in passato e, se non credessi nel suo potenziale, non investirei il mio tempo. Proprio perché penso che valga la pena aspettare, sono disposto a investire tempo ed energie.

Kian: Alistair, vuoi condividere cosa ti sembra interessante di JAM?

Alistair: All'inizio sono stato coinvolto perché qualcuno mi ha contattato per咨询有关JAM的问题，所以就参与进来了。至于JAM有趣的地方，我觉得JAM的数据可用性设计极具魅力，我迫不及待想见证其应用场景。

Se mi chiedete, a cosa serve JAM? Oltre a essere un'estensione di Polkadot, a un livello più profondo, la complessità del protocollo Polkadot ha superato la portata della comprensione di una singola persona. Pertanto, uno degli scopi della stesura del Gray Paper è quello di formulare almeno una specifica di protocollo unificata per una parte di Polkadot, in modo che possa essere compresa. Se può essere compresa chiaramente, il sistema può essere ottimizzato meglio. Pertanto, l'obiettivo di JAM è quello di ottenere prestazioni più elevate rispetto all'attuale Polkadot. Questo è un protocollo molto ambizioso e non vedo l'ora di vederlo alla fine.

Tomek: Scusate, vorrei aggiungere un punto. Dal punto di vista ingegneristico, il progetto JAM è davvero allettante. Si ottiene una specifica completa del protocollo (anche se è in continua evoluzione), si può scegliere qualsiasi linguaggio di programmazione si preferisca per implementarlo e si può essere incentivati tramite il "Programma di premi per l'implementazione JAM". Quindi, anche se non si è ancora pienamente convinti dell'idea di JAM, questa sfida tecnologica aperta è di per sé estremamente attraente.

Daniel: La mia storia è iniziata con PBA (Polkadot Blockchain Academy). Quando mi sono laureato, ho pensato che avrei fatto qualcosa di correlato a Polkadot in futuro, ma la direzione non era ancora stata decisa. Proprio mentre stavo finendo PBA, è stato lanciato il programma JAM, creando una perfetta opportunità con incentivi a premi. Ma il premio è solo un sottoprodotto: anche se non vincessi il premio, la conoscenza accumulata nel processo, la collaborazione con i migliori sviluppatori come Gavin Wood e la profonda comprensione del protocollo sottostante sono inestimabili.

Poiché una volta costruito JAM, ci saranno molti servizi basati su JAM che potranno essere sviluppati, chi conosce i dettagli sottostanti avrà sicuramente un enorme vantaggio. Il motivo per cui mi ci sono dedicato è perché credo fermamente nella visione centrale del Web3 proposta da Gavin molto tempo fa: abbiamo bisogno di un sistema veramente decentralizzato, senza permessi e resistente agli attacchi. Le cosiddette blockchain attuali, che si tratti di Ethereum o altro, sono ben lungi dal raggiungere questo standard. E JAM potrebbe essere la prima volta nella storia dell'umanità che si ha la possibilità di realizzare questa cosa, quindi voglio partecipare con tutto il cuore ed essere uno dei pionieri di tutto questo, e sono anche felice di poter lavorare qui con tutti.

Daniel

Kian: Ottimo punto. Dopo aver ascoltato le presentazioni di tutti, vale la pena notare la diversità del nostro gruppo. In qualità di osservatore, sono felice di vedere sia i "veterani" di Polkadot, come Alistair, che ha iniziato a scrivere codice dall'era di Ethereum, sia le nuove forze emergenti dalla PBA, come Daniel e altri. Spero che questo incoraggi tutti voi presenti a dire: questa strada non è insormontabile. Persone che un anno, due anni o tre anni fa erano sedute in classe come voi, ora stanno implementando manualmente il protocollo JAM. Finché ti impegni, ci sono delle opportunità.

Daniel: Vorrei anche aggiungere che siamo ancora in una fase molto iniziale. Questa strada è lunga, non è uno sprint di 100 metri, ma una maratona. Abbiamo percorso solo il primo chilometro circa e ne mancano più di 40. Quindi, non è affatto troppo tardi per unirsi.

Maciej: Sì, non esitare mai perché pensi che sia "troppo tardi". C'è ancora molto lavoro da fare insieme.

Stato di sviluppo di JAM? 38 team, 15 linguaggi, nessun capo, nessun ordine?

Kian: Ottimo. Daniel, hai menzionato alcune altre squadre e la comunità JAM, potresti approfondire? Ad esempio, qual è l'atmosfera attuale nella comunità JAM? Quali sono i vantaggi di avere così tante persone non correlate che collaborano allo sviluppo? Quali sono le tue impressioni personali?

Daniel: Penso che la progettazione del programma di ricompense JAM sia davvero intelligente. Incoraggia persone provenienti da tutto il mondo, con background diversi, a sviluppare in modo indipendente basandosi sullo stesso progetto (Gray Paper). Nessuno copia gli altri, né interferisce, ma tutti si sforzano di raggiungere lo stesso standard. Se tutti seguono rigorosamente le specifiche, queste implementazioni indipendenti possono essere interconnesse, formando una vera rete decentralizzata.

Abbiamo già iniziato a vedere questo processo. Qualche mese fa, i team hanno iniziato a produrre i propri blocchi e a inviarli ad altri team per la convalida, controllando se fossero conformi alle specifiche. Non si conoscono i dettagli del codice reciproco, ma possono verificarsi a vicenda, il che è di per sé molto eccitante. Naturalmente, a volte si riscontrano piccoli bug e ognuno torna indietro e controlla i propri problemi. In questo modo, l'atmosfera della comunità si è gradualmente formata. Abbiamo anche in programma di tenere un evento JAM Experience a Lisbona a maggio di quest'anno, dove abbiamo in programma di lanciare la JAM Testnet (anche se la possibilità di farlo in tempo è una sfida). Vale anche la pena notare che stiamo anche creando un data center chiamato JAM Toaster per prepararsi a test su larga scala in futuro. Questo cluster supercomputer è dotato di centinaia di core, storage a livello di PB e TB di memoria, in grado di simulare la pressione di una rete reale. A quel punto, diverse implementazioni saranno interconnesse, uno scenario spettacolare.

Tomek: A proposito, forse molte persone non lo sanno ancora, ci sono attualmente 38 team che partecipano pubblicamente, che coprono circa 15 linguaggi di programmazione. Alcune persone potrebbero mettere in dubbio se siano necessarie così tante implementazioni: in realtà, l'obiettivo non è quello di mettere tutte le versioni nell'ambiente di produzione, ma quello di coltivare una comunità di esperti. Proprio come l'attuale Technical Fellowship di Polkadot, ma JAM sceglie di stabilire questa rete di conoscenza prima che il protocollo sia online, gettando le basi per gli aggiornamenti futuri.

Maciej: Sì, uno degli obiettivi principali del premio è quello di promuovere la prosperità dell'ecosistema attraverso la decentralizzazione della conoscenza. PBA, JAM Prize e Fellowship sono tutti per lo stesso obiettivo: far sì che più persone comprendano, partecipino e possano veramente comprendere il protocollo, possano sviluppare strumenti in modo indipendente in futuro e promuovere lo sviluppo dell'ecosistema. Se solo poche persone capiscono, l'intero ecosistema è fragile. Quindi, dobbiamo diffondere la conoscenza per garantire veramente il successo futuro.

Maciej

Kian: Ho anche menzionato un punto nella presentazione di questa mattina. L'importante ruolo dell'attuale Polkadot Technical Fellowship è quello di impedire a qualsiasi singola azienda di diventare un collo di bottiglia di sviluppo o un punto di monopolio della conoscenza. E JAM, attraverso il programma di premi, ha riunito più di 40 team e centinaia di sviluppatori, con una distribuzione avanzata in termini di decentralizzazione della conoscenza. In futuro, la manutenzione e l'aggiornamento di JAM saranno completamente fuori dal controllo di una singola organizzazione, penso che questo sia molto sorprendente.

Cosa stanno facendo questi 38 team di sviluppo? Quali sono i loro obiettivi a breve e medio termine?

Parliamo del futuro: quali obiettivi ogni team di sviluppo spera di raggiungere con JAM e con il proprio team nel prossimo anno? Ad esempio, quali sono gli obiettivi a breve e medio termine?

Tomek: Inizierei io. Per quanto riguarda JAM, spero davvero che ci sia una testnet stabile e funzionante entro un anno. Penso che questo obiettivo sia realizzabile. Per quanto riguarda il nostro team, il linguaggio di programmazione che abbiamo scelto non è il più veloce, quindi potrebbe essere difficile superare Milestone 3 (corrispondente alle prestazioni a livello di Kusama). Tuttavia, di recente ho scoperto un nuovo percorso: ad esempio, non è necessario sviluppare un compilatore PVM ad alte prestazioni da soli, ma è possibile utilizzare le capacità di compilazione del codice nativo di altri linguaggi. Pertanto, il nostro obiettivo è stato modificato per completare la seconda pietra miliare (implementazione delle funzioni di base), dopodiché potremmo passare allo sviluppo di un client leggero del browser per fornire un punto di accesso all'ecosistema JAM.

Daniel: Il nostro team utilizza il linguaggio Elixir, che è ancora un punto interrogativo se ce la farà fino a Milestone 5. Io credo che sia possibile, ma dipende dai progressi. Se non possiamo raggiungere le massime prestazioni, possiamo usare linguaggi di livello inferiore come Rust per gestire le parti più esigenti in termini di prestazioni e lasciare che Elixir si concentri sul controllo e sulla gestione della logica superiore. Credo che Elixir sia molto adatto per questo.

Il mio piano è di rimanere nell'ecosistema JAM per almeno i prossimi dieci anni. Perché dopo che JAM è stato completato, ci sono troppe cose da fare: costruire vari servizi su di esso, aiutare gli altri a sviluppare su JAM. È come entrare in un mondo completamente nuovo. E mi piace molto il modo in cui lavoro ora: nessuna azienda, nessun capo, nessun cliente. Siamo una comunità composta da un gruppo di persone con idee simili, che collaborano liberamente e si condividono a vicenda, questo è il migliore. Spero che questa atmosfera possa essere mantenuta sempre.

Maciej: Concordo anche con il punto di vista di Daniel su Elixir. Ho iniziato a partecipare al progetto JAM solo un mese fa, quindi sono ancora in una fase di apprendimento e familiarizzazione rapida. Onestamente, all'inizio c'erano molte informazioni, ma le sto gradualmente mettendo in ordine.

Ho osservato che la maggior parte dei team si concentra sulla prima pietra miliare (funzione di transizione di stato di base), che sta per affrontare la sfida principale dell'architettura di sharding, che è proprio la direzione che ho studiato e sviluppato a lungo in Polkadot 2.0. Quindi, in futuro, spero non solo di aiutare il mio team, ma anche di condividere le mie conoscenze con più team JAM, aiutandoli a capire il meccanismo di sharding, come fare ELVES (ambiente di esecuzione), come far funzionare insieme le varie parti del sistema. Se tutto va bene, dovremmo essere in grado di vedere i risultati iniziali dell'esecuzione di ELVES su JAM entro un anno. Negli ultimi anni, abbiamo accumulato molta esperienza di ottimizzazione nel campo di Polkadot, ed è ora di trasmettere questa esperienza.

Alistair: Certo, non vedo l'ora! Per quanto mi riguarda, il mio focus è: quali funzionalità possiamo inserire nella prima versione di JAM e quali dobbiamo rimandare a dopo. Ad esempio, il team Tenderbake ha discusso il protocollo DKG (Distributed Key Generation) nelle ultime due settimane. Se JAM può introdurre la tecnologia di crittografia di soglia (threshold cryptography) nella prima versione, il carico di lavoro dei nodi di convalida può essere ridotto del 40%, ovvero, nelle stesse condizioni hardware, la capacità di elaborazione del sistema può essere aumentata del 40%. Questo è un grande miglioramento, ma non sono sicuro che possa raggiungere la prima versione online e immagino che molti sviluppatori in realtà non vogliano raggiungerla ahah, perché ci sarebbero più cose da fare all'inizio.

Kian: A questo punto, vorrei fare una domanda ad Alistair: hai appena detto che JAM avrà aggiornamenti di versione. Allora puoi spiegare come sarà il futuro percorso di aggiornamento di JAM? Perché molte persone all'inizio saranno confuse, Polkadot può essere aggiornato sulla catena, mentre JAM non sembra enfatizzare particolarmente il meccanismo di aggiornamento sulla catena. Qual è la differenza tra questi? Se in futuro sarà necessario eseguire un grande aggiornamento su JAM, sarà necessario riformulare il Gray Paper o anche un hard fork, a causa di quali circostanze?

Alistair: In realtà, l'attuale Polkadot supporta rigorosamente solo gli aggiornamenti di governance on-chain in fase di esecuzione (Runtime), le modifiche sottostanti, come gli algoritmi di consenso, richiedono ancora un hard fork, che non è molto più semplice di Bitcoin. Cosa succederà a JAM? In futuro avrà il suo modello di gestione degli hard fork, che è un nuovo argomento nell'ecosistema Polkadot. Forse, a quel punto, la Fellowship tecnica giocherà un ruolo più importante, dopotutto è già molto importante per gli aggiornamenti di runtime su Polkadot. JAM potrebbe anche avere il suo "ramo della Fellowship" per occuparsi dei futuri cambiamenti importanti, ma onestamente, non abbiamo ancora deciso come fare.

Alistair

Kian: In precedenza ho sentito Gavin menzionare in un'intervista che sembra che un certo hard fork o un importante aggiornamento di versione di JAM in futuro potrebbe comportare la crittografia quantistica (Quantum Resistant Crypto). Alistair, sei più esperto in questo settore, puoi dire se questo è vero? O ho sentito male?

Alistair: Beh, a questo proposito, penso che al momento non ci sia una necessità urgente di crittografia quantistica. Ma la cosa importante è che dobbiamo preparare in anticipo una versione di fork che possa essere commutata in qualsiasi momento. Ora stiamo esaminando le varie primitive crittografiche in Polkadot per vedere quali possono essere facilmente sostituite con la crittografia quantistica. Alcuni posti sono molto semplici, ad esempio, è relativamente facile sostituire le firme a curva ellittica con firme a base di rete standardizzate, ma ad esempio, il VRF (Verifiable Random Function) che usiamo in ELVES e Sassafras, non è così facile usare la crittografia anti-quantistica, potrebbe essere necessario passare a un faro casuale (Randomness Beacon) o al metodo basato su DKG di cui ho parlato prima. Stiamo pensando seriamente a questi problemi, ad esempio, se possiamo prima provarlo su Kusama. Nel complesso, se si lancia un sistema completamente anti-quantistico direttamente su JAM, le prestazioni diminuiranno in una certa misura. Ma la cosa più importante è essere preparati a una versione di fork che possa essere commutata in qualsiasi momento, anche se non verrà abilitata immediatamente a breve termine.

Daniel: Quindi, se si vuole essere anti-quantistici, è necessario sacrificare le prestazioni?

Alistair: Tuttavia, alcune ottimizzazioni del protocollo possono mitigare l'impatto. Ad esempio, l'utilizzo di algoritmi ad alta intensità di hashing può mantenere la velocità, ma aumenterà il consumo di larghezza di banda. Ad esempio, la prova a conoscenza zero (SNARK) da 100 KB originariamente eseguita sulla catena può essere trasferita a un servizio off-chain per l'elaborazione, in modo che le prestazioni della catena non siano influenzate. Il vero punto dolente è l'espansione delle dimensioni della firma, che consuma principalmente spazio di blocco anziché risorse di calcolo.

Tomek: Vale la pena notare che JAM, come protocollo minimalista, non include nativamente meccanismi di token e governance, e tutte le funzionalità devono essere estese sotto forma di servizi. Pertanto, i futuri aggiornamenti si concentreranno sul miglioramento del protocollo sottostante, come il passaggio alla crittografia anti-quantistica o il miglioramento dell'efficienza dei validatori, riducendo il loro carico di lavoro. Inoltre, per giudicare se un hard fork sia necessario, c'è uno standard molto intuitivo: purché si possa dimostrare che questo aggiornamento non comporterà rischi sistemici, ma aumenterà solo le prestazioni o la sicurezza del sistema, tutti generalmente possono accettarlo ed è improbabile che si verifichi una grave divisione nell'opinione della community.

Come sarà il percorso di migrazione da Polkadot a JAM?

Kian: Quindi, cioè, è proprio questo design che rende la probabilità che JAM richieda un hard fork estremamente bassa. Quindi vorrei chiedere a tutti voi presenti, come pensate che saranno i futuri percorsi di aggiornamento e migrazione del sistema Polkadot esistente e dei vari Parachain? Naturalmente, non siamo ancora arrivati a quel punto, ma con la vostra attuale comprensione, potete prevederlo?

Maciej: Penso che questa domanda possa essere divisa in due parti. In primo luogo, è chiaro che i Parachains hanno un posto su JAM. Ogni volta che parlo di JAM, lo sottolineo, i team Parachains esistenti avranno un modo per migrare su JAM e ci saranno servizi speciali per supportare l'esecuzione dei Parachains.

Per quanto riguarda come migrare nello specifico, è piuttosto difficile e alcune persone stanno discutendo se sia necessario un Regenesis (riavvio della catena)? È necessario? Non è ancora stato deciso e tutti stanno ancora analizzando i pro e i contro. Ciò che è certo è che la Fellowship tecnica sarà coinvolta a quel punto, e potrebbe anche essere necessaria una sorta di decisione di governance, ma non è ancora possibile dirlo con certezza.

Alistair: Sì. L'idea più elementare è quella di sviluppare prima un Core Chain Service, che possa supportare l'esecuzione di Parachain su JAM. Molti dei nodi Parachain esistenti sono costruiti su FRAME, usando il framework Cumulus, purché siano leggermente adattati, in teoria possono continuare a funzionare, questo è il primo passo: prima far funzionare la logica. Per quanto riguarda i dettagli della migrazione, ad esempio, come migrare i dati, come mantenere lo stato, questa è un'altra cosa, ed è anche una sfida tecnica molto interessante, ma è la fase successiva da considerare.

Kian: Aggiungo anche che, come ha detto Maciej, l'obiettivo attuale di Parity e Fellowship è quello di rendere il processo di migrazione il più fluido possibile. Naturalmente, siamo ancora nelle prime fasi della pianificazione e il piano specifico deve ancora essere esplorato. Ma la direzione è certa: il più fluida possibile, riducendo l'impatto.

Maciej: Sì, in realtà stiamo vivendo cose simili durante il processo di aggiornamento di Polkadot 2.0, come la migrazione delle funzionalità sulla Relay Chain a vari servizi. Durante questo processo, stiamo anche accumulando molta esperienza di migrazione. Credo che a quel punto, questa esperienza possa fornire molto aiuto per la migrazione di JAM e forse anche permetterci di scoprire e risolvere alcuni potenziali problemi in anticipo.

Kian: Vale la pena notare che nel resto dell'anno, Polkadot ha molti aggiornamenti, l'obiettivo principale è migrare parte della funzionalità dalla Relay Chain alla System Chain, come Asset Hub. Questo non solo migliora il protocollo stesso, l'esperienza utente e l'esperienza degli sviluppatori, ma prepara anche il futuro JAM. Stiamo gradualmente "svuotando" la Relay Chain per renderla il più leggera possibile, in modo che possa essere sostituita senza problemi quando verrà sostituita con JAM in futuro.

Se volete davvero realizzare Web3, l'unica scelta ora è Polkadot e JAM

Infine, ho una domanda aperta e poi la lascerò a tutti per fare domande: qualcuno di voi presenti ha qualche idea o sentimento su JAM che vorrebbe condividere? Ad esempio, qual è il punto che vi eccita di più o cosa vi aspettate dal futuro? Domanda aperta, chiunque può parlare.

Tomek: Questa domanda è troppo aperta ahah, allora parlerò prima dal punto di vista di un ingegnere. Ora in realtà è un'opportunità molto unica, proprio come hanno detto tutti prima, la versatilità di JAM è di gran lunga superiore all'architettura Polkadot esistente, vale a dire che possiamo migrare direttamente i parachain esistenti e possono ancora funzionare normalmente.

Ma la domanda più importante è: cosa possiamo fare oltre a migrare i Parachains esistenti? JAM ci apre molte nuove possibilità, ad esempio: sarà necessario utilizzare la forma di "catena" in futuro? Ci possono essere nuove modalità? Che tipo di nuovi servizi possono essere costruiti su JAM? La cosa più interessante è che non abbiamo nemmeno un framework standard per sviluppare questi servizi. Sebbene Parity e Gavin stiano realizzando un JAM SDK, JAM stesso esegue PVM e gli sviluppatori possono scegliere liberamente il proprio framework di sviluppo, purché alla fine possa essere compilato in PVM. E poiché PVM è basato sull'architettura RISC-V, teoricamente supporta quasi tutti i principali linguaggi di programmazione. Quindi, ciò significa che in futuro tutti potranno utilizzare il proprio linguaggio preferito e definire il framework di sviluppo adatto alla propria applicazione, che diventerà la base del futuro ecosistema JAM.

Tomek

Daniel: Il mio pensiero potrebbe essere un po' più filosofico. Se credete veramente nell'ideale di Web3: decentralizzazione, resistenza alla censura, la catena può essere completamente auto-gestita senza dipendere da alcuna entità centralizzata, allora vorrei dire che, al momento, solo Polkadot e JAM stanno ancora veramente insistendo nel fare questo. Guardate gli altri, come Ethereum, l'attuale Ethereum è in realtà "bloccato", anche la tecnologia è obsoleta e la comunità difficilmente può promuovere grandi aggiornamenti. E le altre catene che pretendono di superare Ethereum sono essenzialmente gestite da alcune società centralizzate, una o due entità possono controllare la situazione. Anche l'espansione di secondo livello (L2) di Ethereum, come Base, Arbitrum, queste sono in realtà centralizzate, essenzialmente contrarie all'ideale di Web3.

Se volete davvero fare un Web3 significativo, l'unica scelta ora è Polkadot e JAM. Naturalmente, per trasformare questo ideale in realtà, è necessario che più persone lavorino insieme. Stiamo lavorando sodo per attirare più persone ad aderire. Più persone ci sono, prima raggiungeremo questo obiettivo.

Alistair: Sì, sono completamente d'accordo. Il sogno di Polkadot e JAM è quello di poter costruire veramente protocolli decentralizzati e resistenti alla censura. Sebbene ci siano ancora alcune sfide nella progettazione attuale, ad esempio, ci sono alcuni punti che richiedono ancora maggiore esplorazione e innovazione, ma continueremo ad andare avanti.

Maciej: La mia sensazione è questa: come il primo prototipo di blockchain frammentata, sebbene molte delle nostre progettazioni siano corrette, ci siamo anche resi conto lungo il percorso che alcune cose possono essere fatte meglio. JAM è proprio un'opportunità per noi di ripulire il "debito tecnico" accumulato negli ultimi anni. Possiamo riprogettare con un modo più astratto e conciso per creare un protocollo che sia davvero vicino allo stato ideale.

Inoltre, alcune persone ritengono che il protocollo Polkadot sia difficile da comprendere, ma in futuro con JAM, questa situazione migliorerà molto. Perché JAM conserva solo le cose più importanti e necessarie, la logica è semplice e l'architettura è chiara. In questo modo, sia gli sviluppatori che la comunità potranno capirlo molto più facilmente. In realtà, non solo la blockchain, ma tutti i grandi sistemi software accumulano debiti tecnici, ma la maggior parte dei progetti ha poche possibilità di essere completamente ristrutturata. Ora stiamo cogliendo questa opportunità per fare le cose per bene.

Alistair: Vorrei aggiungere che ora non sappiamo ancora quali nuove cose possono essere finalmente realizzate su JAM. Ma speriamo che le varie astrazioni e la progettazione della generalizzazione in JAM possano aprire nuove possibilità. Ad esempio, Gavin ha proposto un'idea di "Coreplay" in passato, che è un nuovo modo di pensare che va oltre gli attuali parachain. Sebbene quell'idea non sia diventata formalmente una PR (pull request) all'epoca, e la versione sia relativamente vecchia, se siete interessati, potete andare a scavare nel repository RFC della Polkadot Fellowship, dove ci sono alcune fonti di ispirazione.

Maciej: Vorrei anche aggiungere una frase, potrebbe essere un po' "velenosa". Se l'ecosistema JAM è alla fine solo una copia del Parachain, allora sarà un completo fallimento. Ci aspettiamo che si possano sviluppare più cose nuove basate su JAM! Coreplay è una parte che aspetto con particolare impazienza e spero sinceramente che possa essere realmente applicato su JAM in futuro.

Kian: Ok, grazie a tutti per la condivisione! Allora dopo, prenderò il microfono e farò un giro per il luogo, tutti possono fare domande liberamente!

Il testo seguente riguarda principalmente le domande e risposte della community, PolkaWorld pubblicherà domani!

#JAM #Polkadot