JAM è dopo la versione 2.0, ed è attualmente in fase di sviluppo accelerato, con oltre 30 team diversi, in vari linguaggi di programmazione, che lavorano per realizzare un client JAM decentralizzato (basato sul protocollo JAM white paper). Il primo ETH richiedeva che tutte le transazioni fossero verificate da tutti i validatori (questa parte può essere approfondita consultando il white paper di Ethereum, e c'è anche una versione interpretativa migliore). L2 consente a un sottoinsieme più piccolo di operare off-chain, attraverso due modalità: una è la prova di frode (dove, una volta scoperta una frode, il codice della transazione viene rieseguito per la verifica), l'altra è la prova zk, che non richiede riesecuzione, ma necessita di GPU costose per generare la prova; sulla chain si verifica solo la prova, senza dover rieseguire il codice della funzione di transazione precedente. Inizialmente, @Polkadot 1.0 utilizzava un algoritmo chiamato ELVES, che non è come l'algoritmo di frode di ETH, che verifica passivamente, ma utilizza un algoritmo di tipo probabilistico per la verifica attiva. Con @polkadot 2.0, il set di validatori è stato impacchettato in un concetto chiamato Core, che è essenzialmente un sottoinsieme del set di validatori. La versione 2.0 supporta Agile Coretime, il che significa che un chain può utilizzare dinamicamente il core in base alle necessità; nella versione 1.0, un chain poteva utilizzare solo un Core, mentre con la 2.0, dopo il lancio, sarà possibile utilizzare Agile Coretime, consentendo a un chain di utilizzare dinamicamente il coretime (numero di sottoinsiemi di validazione), migliorando così il carico di lavoro del sistema. JAM si basa su queste idee e ha evoluto il concetto, introducendo zk, op, smart contract, e persino applicazioni senza stato di tipo web2; può ulteriormente astrarre i servizi per adattarsi a questi diversi modelli applicativi e consentire interazioni combinabili tra di loro. Quindi, JAM ha fatto un ulteriore passo avanti in questa astrattizzazione. - Varie cose L2/chain parallele sono ora chiamate servizi - Le cose relative a blocchi/transazioni sono ora chiamate elementi di lavoro o pacchetti di lavoro - Gli elementi di lavoro appartengono ai servizi, mentre i pacchetti di lavoro sono un insieme di elementi di lavoro - I servizi sono descritti da tre punti di ingresso, due dei quali sono fn refine() e fn accumulated - Questi due nomi di punti di ingresso sono proprio il motivo per cui il protocollo è chiamato JAM: Join Accumulate Machine. Join si riferisce a fn refine(), dove tutti i core di Polkadot eseguono in parallelo un gran numero di lavori per diversi servizi. Join significa estrarre i dati in un sottoinsieme più piccolo e poi passarli alla fase successiva. - Accumulate significa accumulare i risultati di tutte le operazioni sopra nel principale stato JAM - Vengono supportate diverse forme di servizi (op rollups, zkrollups, chain parallele, applicazioni senza stato, smart contract) L'era ETH è una macchina a stato singolo condiviso, L'era @polkadot 1.0 è una macchina a frammentazione probabilistica interoperabile. L'era @polkadot 2.0 è una macchina Agile Coretime. L'era JAM è Join Accumulate Machine (JAM). Ci sono molte altre caratteristiche dettagliate, qui ho solo fatto una sintesi delle informazioni che ho compreso; per una comprensione più profonda del perché JAM possa eseguire programmi in modo continuo senza dover attivare il programma tramite transazioni, quali nuovi modelli di prodotto potrebbero emergere in futuro combinando queste caratteristiche con DEFI? Perché JAM può eseguire applicazioni senza stato, come JAM DOOM. Per ulteriori dettagli, vedere il video: Materiale di studio: