Solana: l’ingegneria dietro la velocità | CRYPTO

0:00 Speaker 2: Siete su due pagine.

0:01 Speaker 3: Questo è l'episodio speciale della domenica. Oggi andiamo a fondo sull'architettura, l'economia e la scalabilità dell'ecosistema Solana.

0:09 Speaker 2: Allora, immaginiamo un supermercato grande quanto il mondo intero.

0:13 Speaker 3: Un ipermercato globale, praticamente.

0:15 Speaker 2: Sì, un ipermercato globale con milioni di clienti che premono alle porte ogni singolo secondo, cioè con i carrelli pieni pronti a pagare. Sì. Però c'è un problema fisico insormontabile. L'intera struttura, per quanto colossale, ha una sola cassa aperta.

0:32 Speaker 3: E i clienti devono mettersi tutti in fila indiana?

0:35 Speaker 2: Esatto, in un'unica infinita fila indiana. Non importa quanto si sia veloce a fare la spesa, il flusso si arresta e si strozza tutto in quel singolo punto di pagamento.

0:45 Speaker 3: Che poi, spogliato di ogni gergo tecnico, questo è esattamente il limite strutturale delle architetture su cui si basano le criptovalute tradizionali.

0:53 Speaker 2: È la rappresentazione fisica del trilemma della blockchain, no?

0:57 Speaker 3: Sì, quel principio che costringe l'ingegneria di questi sistemi è un compromesso continuo tra decentralizzazione, sicurezza e scalabilità.

1:04 Speaker 2: La regola non scritta è sempre stata una, ovvero se vuoi un sistema sicuro e distribuito devi per forza sacrificare la velocità.

1:14 Speaker 3: E i numeri storici riflettono proprio questo collo di bottiglia, cioè Bitcoin che ha estremizzato la sicurezza tramite la Proof of Work...

1:21 Speaker 2: Processa tipo 7 transazioni al secondo

1:24 Speaker 3: 7. Ethereum, persino dopo la sua immensa transizione alla Proof of Stake, naviga sul suo strato primario, Layer 1, tra le 15 e le 30 transazioni al secondo.

1:34 Speaker 2: Ma il motivo di questa lentezza non è che il codice sia scritto male?

1:38 Speaker 3: No, affatto. È una scelta architettonica voluta. È il paradigma di esecuzione sequenziale. La famosa singola cassa del supermercato.

1:45 Speaker 2: Quindi ogni transazione, che sia... lo spostamento di un milione di dollari o l'acquisto di un'immagine digitale da tre centesimi

1:54 Speaker 3: deve essere elaborata una dopo l'altra, sempre,

1:58 Speaker 2: all'interno di un unico flusso computazionale.

2:00 Speaker 3: E questo ovviamente genera congestione, attese infinite e nei momenti di picco i costi di commissione esplodono.

2:07 Speaker 2: Chiaro, perché gli utenti iniziano a fare offerte più alte per saltare la fila.

2:11 Speaker 3: Ed è qui che definiamo l'obiettivo della nostra analisi di oggi. Vogliamo smontare pezzo per pezzo un'infrastruttura che ha deciso semplicemente di ignorare questo compromesso della singola cassa.

2:22 Speaker 2: Parliamo di un salto ingegneristico che porta il limite teorico da 30 a 50 mila transazioni al secondo.

2:29 Speaker 3: Ma il dettaglio veramente cruciale, quello che rende questa architettura un caso di studio fondamentale per noi, è che questo throughput pazzesco viene raggiunto sulla rete principale.

2:39 Speaker 2: Niente letti secondarie. Zero. Niente layer 2 che smistano il traffico fuori dalla rete primaria e niente sharding per frammentare il database.

2:49 Speaker 3: È un approccio totalmente monolitico, un singolo stato globale progettato per scalare di pari passo con l'evoluzione dell'hardware puro e semplice.

2:57 Speaker 2: Per capire come una rete possa fisicamente processare decine di migliaia di eventi al secondo a livello globale, bisogna prima risolvere il problema forse più invisibile eppure devastante dei sistemi informatici distribuiti.

3:11 Speaker 3: Il tempo

3:11 Speaker 2: La natura del tempo. In un sistema centralizzato, tipo i server di una banca, c'è un orologio interno che detta legge, no? Tutti gli eventi vengono registrati secondo quell'orologio lì.

3:22 Speaker 3: Ma in una rete decentralizzata con migliaia di computer sparsi tra Tokyo, New York e Francoforte?

3:28 Speaker 2: Non c'è nessun orologio centrale.

3:30 Speaker 3: Esatto. Mettiamola in termini pratici. Se un nodo in Giappone e uno in Germania ricevono due transazioni nello stesso esatto millisecondo...

3:39 Speaker 2: A causa dei tempi di latenza di Internet, le percepiranno in modo diverso.

3:43 Speaker 3: Eh sì, percepiranno l'ordine degli eventi in modo diverso. Come fanno a mettersi d'accordo su chi è arrivato prima senza un orologio condiviso?

3:51 Speaker 2: Nei sistemi classici passano il tempo a parlarsi. I computer devono inviarsi continui messaggi, aspettare le risposte, confrontare i dati e votare.

4:01 Speaker 3: Solo per stabilire l'ordine cronologico degli eventi.

4:03 Speaker 2: E solo dopo aver concordato che ore sono, possono iniziare a impacchettare le transazioni.

4:09 Speaker 3: Che è un traffico di coordinamento che divora un'enorme fetta della larghezza di banda disponibile. un sovraccarico strutturale che paralizza le prestazioni prima ancora di iniziare a lavorare sul serio.

4:19 Speaker 2: La soluzione a questo caos temporale è il concetto di proof of history e su questo bisogna essere categorici per evitare un malinteso gigantesco che circola spesso.

4:29 Speaker 3: Che sia un meccanismo di consenso.

4:32 Speaker 2: Esatto. La Proof of History non è un meccanismo di consenso. Non stabilisce chi ha ragione, non valida i blocchi e non difende dagli hacker.

4:40 Speaker 3: È puramente e semplicemente un orologio crittografico interno.

4:44 Speaker 2: Si basa su una funzione matematica che si chiama Verifiable Delay Function.

4:48 Speaker 3: Praticamente il cuore di questo orologio è l'algoritmo di hashing SHA- 256. Invece di usarlo una volta sola, il sistema lo fa girare in un loop infinito. Un ciclo continuo. Sì, un ciclo continuo. La genialità sta nel fatto che l'output, cioè il risultato finale di un calcolo, diventa obbligatoriamente l'input del calcolo successivo.

5:09 Speaker 2: Quindi crea una catena

5:11 Speaker 3: di dipendenza assoluta. Esatto. Non esiste alcun modo per prevedere il risultato del millesimo passaggio senza aver calcolato fisicamente e in sequenza tutti i 999 passaggi precedenti.

5:22 Speaker 2: Non puoi dividerlo su più processori per fare prima, insomma.

5:26 Speaker 3: Impossibile. Richiede un tempo fisico reale, un ritardo matematicamente insopprimibile e soprattutto dimostrabile.

5:33 Speaker 2: L'analogia perfetta per capire la proof of history è la classica prova di vita nei film sui rapimenti, no?

5:39 Speaker 3: I rapitori con il giornale in mano all'ostaggio.

5:41 Speaker 2: Eh, i rapitori scattano una foto all'ostaggio con la prima pagina del quotidiano di oggi. Quella foto contiene un'informazione inconfutabile, cioè lo scatto non può essere avvenuto ieri, perché il giornale di ieri non aveva quella notizia.

5:55 Speaker 3: La Proof of History fa la stessa identica cosa, ma con la criptografia. Quando una transazione arriva alla rete, viene per così dire fotografata, insieme al risultato corrente, del ciclo SHA- 256. L'hash della transazione si fonde con il battito dell'orologio, in quel preciso istante.

6:11 Speaker 2: E in questo modo l'evento viene ancorato per sempre a una coordinata temporale esattissima.

6:17 Speaker 3: La transazione si porta dietro la prova matematica di essere avvenuta dopo il battito precedente e prima di quello successivo.

6:24 Speaker 2: Il vantaggio operativo monumentale di questa struttura salta fuori nella fase di controllo,

6:30 Speaker 3: giusto? Assolutamente. Il nodo che ha il compito di creare il blocco deve sudare, deve faticare e spendere tempo reale per generare questa sequenza riga dopo riga.

6:40 Speaker 2: Ma quando invia questo blocco agli altri 10.000 computer per la verifica?

6:45 Speaker 3: Accade la magia, perché la verifica non ha bisogno di seguire la sequenza lineare.

6:49 Speaker 2: Mentre la creazione procede in fila indiana, la verifica viene parallelizzata.

6:54 Speaker 3: Un computer che riceve il blocco spezza l'enorme sequenza di hash in mille pezzi e gli dà in parastoi mille corde la sua scheda video simultaneamente.

7:03 Speaker 2: Quindi la validazione da parte del resto del mondo è quasi istantanea.

7:07 Speaker 3: Tutti i computer della rete possono concordare sull'ordine esatto degli eventi senza doversi scambiare nemmeno un messaggio preliminare.

7:15 Speaker 2: Ok, quindi l'infrastruttura ora sa che ore sono. Il tempo è codificato nei dati stessi. Ma sapere l'ora non sposta i pacchetti di rete.

7:24 Speaker 3: Eh no, i dati pesano.

7:26 Speaker 2: Se la rete deve digerire 50.000 operazioni al secondo, genera una mole di dati mostruosa. Come si trasmettono e si approvano questi dati senza far collassare tutto?

7:36 Speaker 3: Entriamo nel vivo dell'architettura senza code. Il primo tassello è il modo in cui i nodi votano, che è il vero meccanismo di consenso, noto come Tower BFT. La dinamica si gioca sui vincoli economici. Quando un nodo decide di votare per approvare un determinato blocco, si autoinfligge un periodo di blocco, un lockout. E per tutta la durata di questo intervallo, quel nodo non ha il permesso di cambiare idea e votare per una versione alternativa della storia.

8:01 Speaker 2: E la progressione di questo lockout è punitiva, no? È un raddoppio esponenziale continuo.

8:07 Speaker 3: Sì, se un nodo vota per una sequenza di blocchi consecutivi, il suo vincolo economico si moltiplica. Questo serve a forzare la convergenza.

8:14 Speaker 2: Cioè, se sei indeciso o se stai cercando di manipolare la rete votando su due versioni diverse, il sistema ti penalizza congelandoti per tempi sempre più lunghi.

8:24 Speaker 3: I validatori sono incentivati a concordare sulla verità più solida il prima possibile. Questo si lega a un principio architettonico netto.

8:32 Speaker 2: Che tra avere una rete che si blocca completamente in attesa dell'unanimità o una rete che continua a funzionare anche se una piccola parte dei nodi è disconnessa,

8:41 Speaker 3: questa infrastruttura sceglie la seconda. Privilegia la continuità operativa, la cosiddetta liveness, rispetto a una coerenza rigida assoluta.

8:49 Speaker 2: Questo ci risolve l'approvazione logica, ma resta il problema fisico vero e proprio. La larghezza di banda.

8:56 Speaker 3: Il macigno fisico.

8:57 Speaker 2: Mettiamo caso che un nodo leader abbia appena compinato un blocco con decine di migliaia di transazioni. Questo blocco può pesare gigabyte. Certo. Se dovesse prendere questo file enorme e spedirlo per intero a ciascuno dei 10.000 validatori sparsi per il mondo, la sua connessione esploderebbe in un istante.

9:15 Speaker 3: Sarebbe matematicamente impossibile propagare i dati a quelle velocità con un approccio lineare. E la risposta arriva, stranamente, dai protocolli di condivisione file dei primi anni 2000

9:24 Speaker 2: Roba come BitTorrent.

9:25 Speaker 3: Esattamente. Il protocollo si chiama Turbine. L'intuizione dietro Turbine è che spedire un monolite di dati uccide la latenza, mentre spedire polvere di dati è super efficiente. Il nodo leader prende il blocco e lo fa a

9:36 Speaker 2: fette microscopiche, i famosi shreds.

9:42 Speaker 3: E a questi frammenti vengono iniettati algoritmi speciali di correzione degli errori. Quindi, se durante il viaggio su internet qualche pacchetto va perso,

9:49 Speaker 2: Cosa che succede continuamente?

9:51 Speaker 3: I nadi che li ricevono usano la matematica per ricostruire i dati mancanti, senza dover chiedere al leader di rimandarli. Questo fa risparmiare un tempo pazzesco.

9:58 Speaker 2: Quindi il leader... catena.

10:10 Speaker 3: Una struttura d'albero.

10:11 Speaker 2: Spiegami un po' meglio questa cascata.

10:13 Speaker 3: Il leader invia i frammenti a un primo strato di nodi. Questi nodi prendono i dati istantaneamente e li inoltrano a un secondo strato. E così via.

10:21 Speaker 2: Usando un fattore di ramificazione? Il

10:23 Speaker 3: fan- out, sì. È impostato a 200. Il nodo al vertice spedisce a 200 macchine. Ognuna di queste spedisce ad altre 200

10:31 Speaker 2: Si trasforma un problema lineare da 10.000 operazioni in un problema logaritmico.

10:36 Speaker 3: Con soli tre passaggi di rete arrivi a centinaia di migliaia di destinazioni potenziali. È rapidissimo.

10:41 Speaker 2: Però c'è ancora un elemento in questa architettura che devia brutalmente dallo standard e riguarda la totale eliminazione della mempool.

10:49 Speaker 3: Ah, la sala d'attesa!

10:50 Speaker 2: Facciamo un passo indietro per far capire quanto sia grossa questa scelta. Nei sistemi tradizionali, la mempool è una sala d'attesa. Quando invi una transazione, non va subito in un blocco.

11:03 Speaker 3: Finisce in un atrio enorme, pieno di tutte le altre transazioni del mondo.

11:08 Speaker 2: E i nodi scelgono chi paga le commissioni più alte. Se paghi poco, rimani nella sala d'attesa per ore.

11:15 Speaker 3: Gulfstream è il protocollo che letteralmente rada al suolo questa sala d'attesa. Non c'è nessuna mempool pubblica.

11:23 Speaker 2: L'eliminazione della mempool cambia il flusso dei dati. Il protocollo può farlo perché la programmazione della leadership è conosciuta in anticipo per un intero ciclo, la cosiddetta epoca.

11:35 Speaker 3: Ogni singolo computer sa esattamente quale validatore produrrà il blocco tra un secondo, due secondi, cinque secondi.

11:43 Speaker 2: Quindi i software smettono di buttare le transazioni in un calderone generico. Le spediscono direttamente, tipo proiettile, al nodo che sta per diventare leader.

11:54 Speaker 3: È come se i clienti del supermercato andassero dritti dalla cassiera che sanno aprirà il turno tra 30 secondi e iniziassero a mettere la spesa sul nastro.

12:02 Speaker 2: Prima ancora che lei si sieda, il nodo riceve i dati in streaming e li decodifica in anticipo. Ma aspetta.

12:10 Speaker 3: Dimmi.

12:10 Speaker 2: Se io lancio una transazione al leader futuro e questo leader improvvisamente perde la connessione internet o va in crash...

12:17 Speaker 3: Cosa succede ai fondi?

12:19 Speaker 2: Non essendoci una sala d'attesa in cui tornare, la mia operazione non rimane incastrata come un fantasma nel sistema.

12:25 Speaker 3: Questo è un rischio tecnico reale. Ed è qui che la Proof of History rientra in gioco come strumento di igiene della rete. Ogni transazione ha dentro un hash di riferimento che fa da data di scadenza strettissima. Un time to live.

12:38 Speaker 2: La rete impone una regola ferrea. O la transazione viene finalizzata entro questo breve intervallo di tempo criptografico o decade istantaneamente.

12:47 Speaker 3: Diventa invalida. Se il nodo leader si disconnette, i secondi passano, l'hash scade e la transazione viene scartata dal protocollo.

12:56 Speaker 2: I fondi rimangono nel portafoglio dell'utente.

12:59 Speaker 3: Esatto, senza dover fare niente. E la memoria dei validatori non si intasa di transazioni bloccate.

13:05 Speaker 2: Ok, quindi i dati viaggiano leggeri, il tempo è scandito in modo chirurgico, le code non ci sono più, ma arriviamo all'ultimo ostacolo fisico.

13:15 Speaker 3: L'elaborazione logica.

13:17 Speaker 2: Puoi far arrivare 50.000 transazioni sulla scheda di rete, ma se il processore non riesce a eseguirle, tutto si ferma lì.

13:24 Speaker 3: Il nuovo collo di bottiglia diventa la CPU.

13:27 Speaker 2: Per capire il motore di esecuzione 6-level, guardiamo il suo antagonista storico, cioè la macchina virtuale di Ethereum, l'EVM. L'EVM è un ambiente single- thread. È un'autostrada o una sola corsia.

13:40 Speaker 3: Che significa che la macchina virtuale prende una transazione, la esegue, aggiorna i saldi... e solo dopo passa alla successiva, rigorosamente in serie.

13:51 Speaker 2: Che è uno spreco colossale dell'hardware moderno.

13:54 Speaker 3: Oggi un processore standard ha 16, 32 o 64 core. Usare un solo thread significa tenere accesi 64 core e farne lavorare uno solo.

14:05 Speaker 2: C- Level rovescia questo paradigma con l'elaborazione massivamente parallela. Trasforma quell'autostrada a una corsia in un'autostrada a 64 corsie.

14:16 Speaker 3: dove migliaia di smart contract girano letteralmente nello stesso istante sui vari

14:21 Speaker 2: core. Però frena un attimo. Se ho mille operazioni che sfrecciano in parallelo, come si evita il disastro totale dei dati?

14:29 Speaker 3: La collisione.

14:30 Speaker 2: Mettiamo che io e te premiamo invia nello stesso millisecondo per trasferire fondi verso lo stesso identico account o per comprare lo stesso asset digitale. Se due transazioni tentano di sovrascrivere lo stesso pezzo di memoria, nello stesso momento il database si corrompe.

14:47 Speaker 3: Assolutamente. E Sea Level lo impedisce con una regola brutale ma efficace. La dichiarazione di stato preventiva.

14:55 Speaker 2: Nessuna transazione entra nel motore di esecuzione senza dichiarare in anticipo quali celle di memoria leggerà e quali modificherà.

15:02 Speaker 3: Lo sviluppatore deve allegare una lista dicendo« questa transazione leggerà i dati da X e scriverà su Y».

15:08 Speaker 2: Quindi il pianificatore di sistema ha una mappa chiarissima di cosa toccherà ogni transazione prima ancora di farla partire.

15:14 Speaker 3: Esatto. Quando entra un blocco da 50.000 transazioni, Sea Level analizza queste dichiarazioni. Se la transazione A tocca l'account di Alice e la B tocca Bob,

15:24 Speaker 2: nessun conflitto.

15:26 Speaker 3: Le spara su due core separati e le calcola simultaneamente. Se invece la C e la D dichiarano intame di voler scrivere su Charlie,

15:34 Speaker 2: rileva la potenziale collisione

15:36 Speaker 3: e le fa passare in modalità sequenziale una dopo l'altra. Ma statisticamente la maggior parte del traffico non ha sovrapposizioni, quindi con rimangono tutti belli carichi di lavoro.

15:46 Speaker 2: L'ottimizzazione del software però è solo a metà dell'opera. Si usano tecniche di sfruttamento dell'hardware che sembrano prese dai supercomputer.

15:54 Speaker 3: Il pipelining spinto al limite.

15:56 Speaker 2: Esatto. Il lavoro non viene dato tutto alla CPU, ma spezzettato e distribuito come in una catena di montaggio. Nessuna componente sta con le mani in mano ad aspettare le altre.

16:06 Speaker 3: Quando i pacchetti arrivano dalla rete, vengono intercettati. C'è un'operazione computazionalmente pesantissima in ogni transazione, che è la verifica della firma criptografica.

16:15 Speaker 2: Capire se la firma digitale è valida richiede calcoli su curve ellittiche. La CPU è pessima in questo.

16:23 Speaker 3: Quindi il sistema scarica brutalmente il compito sulle schede video, le GPU. Le schede video sono nate per i videogiochi, sono perfette per processare migliaia di firme vettoriali in parallelo.

16:33 Speaker 2: E mentre la GPU fa i conti matematici, la CPU è già passata a eseguire il codice della transazione precedente e nel frattempo l'SSD sta già salvando il risultato finale.

16:44 Speaker 3: Ogni pezzo di silicio fa una cosa sola di continua.

16:46 Speaker 2: E per gestire l'accesso simultaneo alla memoria senza bloccare i dischi, non usano un database classico. Usano un sistema che si chiama Cloud Break, che mappa i file direttamente tra la RAM e i dischi ad alta velocità.

16:59 Speaker 3: Però c'è l'elefante nella stanza.

17:01 Speaker 2: Il peso dei dati.

17:02 Speaker 3: Se scrivi 50.000 transazioni al secondo ogni giorno accumuli un peso terrificante, terabyte su terabyte.

17:08 Speaker 2: Se costringi i validatori a tenere tutto lo storico dal blocco zero sui loro dischi, in un anno le macchine costerebbero centinaia di migliaia di dollari.

17:17 Speaker 3: Distruggeresti la decentralizzazione. Solo le multinazionali potrebbero gestire un nodo. E allora come risolvono questa obesità del database?

17:25 Speaker 2: Disaccoppiando l'esecuzione dalla conservazione. Il nodo validatore, che spende risorse estreme per far girare C- Level, mantiene nella sua RAM solo lo stato attivo.

17:35 Speaker 3: Cioè l'ultimo aggiornamento dei saldi e dei contratti.

17:39 Speaker 2: Esatto. Tutto lo storico dei mesi precedenti viene spinto fuori e affidato a una rete secondaria di nodi chiamati archivers.

17:46 Speaker 3: Che non partecipano al consenso e non devono avere processori costosi. Sono un immenso hard disk distribuito.

17:51 Speaker 2: Ma siccome non ci si può fidare ciecamente che salvino i dati senza barare, serve una prova matematica, la proof of replication.

17:59 Speaker 3: Gli archivers scaricano porzioni di registro compresse. A intervalli regolari, la rete manda loro una sfida criptografica. Se l'archiver non possiede fisicamente i dati sul suo disco,

18:09 Speaker 2: fallisce la sfida matematica.

18:11 Speaker 3: E così l'onere dello storage viene distribuito su hardware economico, liberando i nodi ad altre prestazioni per l'elaborazione.

18:18 Speaker 2: Tutto molto bello, però queste macchine, CPU da decine di core, GPU pazzesche, fibra ottica, costano capitali immensi.

18:27 Speaker 3: Il ferro costa, l'energia costa.

18:29 Speaker 2: Abbandoniamo i byte ed entriamo nella tokenomics. Come si sostengono economicamente le aziende che fanno girare i validatori?

18:36 Speaker 3: Si parte dal token nativo, SOL, che non ha un limite rigido di offerta come i 21 milioni di bitcoin.

18:43 Speaker 2: Ha un modello deliberatamente disinflazionistico.

18:46 Speaker 3: L'emissione continua di nuova moneta paga chi mette in staking il capitale per validare le transazioni. La rete è partita con un'inflazione annua dell'8%.

18:55 Speaker 2: Ma non è statica. È progettata per ridursi gradualmente con un tasso di disinflazione del 15% per ogni anno- epoca.

19:04 Speaker 3: Che sono circa 182 epoche. La discesa continua fino a un tasso terminale fisso.

19:10 Speaker 2: Che è l'1,5% anno. Ma la resa reale per l'utente, la resa nominale dello stacking, la NSY, dipende da vari fattori.

19:20 Speaker 3: L'inflazione globale, l'uptime del validatore, perché se il tuo server va offline prendi multe. la commissione trattenuta e il tasso di partecipazione globale.

19:30 Speaker 2: Ovvero quanta percentuale dell'offerta totale è in staking. Se tanti mettono in staking, l'inflazione si divide tra più persone e il rendimento scende. Se in tanti prelievano, chi rimane guadanga di più. Si autobilancia.

19:45 Speaker 3: Questa è l'emissione. Ma c'è anche un meccanismo deflazionistico aggressivo.

19:49 Speaker 2: Il protocollo guadagna brucia sistematicamente i propri token. Il 50% delle commissioni di base pagate dagli utenti viene rimosso permanentemente dall'esistenza.

19:59 Speaker 3: Una distruzione di valore che fa da contrappeso. E ultimamente si discute animatamente di due proposte di governance per modificare questi parametri.

20:12 Speaker 2: La Sinsimd 555 è un intervento brutale. Vuole raddoppiare il tasso di disinflazione dal 15 al 30% annuo.

20:21 Speaker 3: Costringendo la rete a raggiungere il tasso terminale dell'1,5% in soli tre anni invece che in un decennio.

20:28 Speaker 2: Stringe la massa monetaria per forzare i capitali a cercare rendimenti nell'economia reale dei protocolli. non solo stando seduti sull'inflazione.

20:37 Speaker 3: Mentre l'altra proposta, la Sinsimd 553, cambia la fornace dove si bruciano i token. Invece di bruciare una tariffa base fissa, lega la distruzione al calcolo fisico.

20:47 Speaker 2: Le Compute Units, cioè più il contratto è pesante da calcolare, più si bruciano token.

20:54 Speaker 3: Si stima che si passerebbe da bruciare 600-800 token al giorno a 7500 o 9000 token giornalieri. Più l'uso industriale della rete cresce, più la valuta diventa scarsa.

21:07 Speaker 2: Parlando di costi reali, però, l'ingegneria economica di questo sistema affronta un problema molto più terreno.

21:13 Speaker 3: Lo spazio fisico.

21:15 Speaker 2: È la REM. I dati caricati in RAM costano ai validatori. Torniamo al supermercato. Se un milione di persone apre una cassetta di sicurezza lì, ci mette uno scontrino e non torna mai più

21:26 Speaker 3: Supermercato esaurisce lo spazio e fallisce.

21:29 Speaker 2: Chi paga per lo spazio fisico occupato dai milioni di account vuoti e abbandonati che intasano la rete? Qui entra in gioco l'affitto dello Stato, il rent. Nulla è

21:40 Speaker 3: gratis sulla memoria on- chain. Ogni byte caricato nei registri richiede una frazione di token come deposito.

21:46 Speaker 2: Ma non a fondo perduto.

21:48 Speaker 3: Esatto. Se metti un saldo minimo che copre due anni teorici di affitto, l'account diventa rent exempt, esente. I fondi rimangono lì come garanzia.

21:58 Speaker 2: È un incentivo perfetto per l'igiene digitale. Nelle vecchie email non cancelliamo mai nulla perché l'archivio è gratis. Qui, se conservi spazzatura, paralizzi il sistema.

22:09 Speaker 3: Quindi l'utente è incentivato a pulire. Se decidi di smantellare un vecchio smart contract inutilizzato e cancelli i dati, liberi spazio vitale nella RAM dei nodi globali.

22:20 Speaker 2: E in cambio, il protocollo ti restituisce immediatamente il saldo che avevi versato come cauzione. È l'antidoto definitivo all'accumulo di scorie digitali.

22:29 Speaker 3: E il costo dello spazio ci porta diretti al punto in cui l'informatica incontra l'economia industriale. La potenza di C- Level combinata con la gestione dei costi di memoria rende possibili modelli di business che prima erano fantascienza.

22:42 Speaker 2: Come la State Compression, la compressione dello stato, usata per gli asset digitali su vasta scala, i famigerati NFT.

22:51 Speaker 3: Creare un NFT tradizionale significa aprire account, allocare byte nella RAM e pagare la cauzione dell'affitto.

22:58 Speaker 2: Per un'opera d'arte va benissimo. Ma immaginiamo un videogioco che deve emettere milioni di spade, scudi e armature a ogni giocatore, ogni giorno.

23:07 Speaker 3: O un sistema ferroviario che emette biglietti tokenizzati. Su un'architettura non compressa, emettere un milione di asset richiede un esborso tra i 12.000 e i 24.000 token nativi solo per la RAM.

23:19 Speaker 2: Si parla di milioni di dollari. Il modello di business muore in partenza.

23:24 Speaker 3: La State Compressions posta festicamente i dati per schiacciare questo costo.

23:28 Speaker 2: Li confina nei registri storici. Togliamo il peso dalla ramma attiva. Ma se i dati non sono più nello stato attivo, come faccio a dimostrare che sono il proprietario di quel biglietto del treno?

23:38 Speaker 3: Si usa l'albero di Merkle concorrente. Le informazioni di milioni di asset vengono scritte nei log storici passive. Vengono compresse matematicamente nei rami di un gigantesco albero crittografico.

23:50 Speaker 2: L'unica informazione che finisce davvero nella costosa memoria on- chain dei validatori è la punta di questo albero, la Merkle root.

23:58 Speaker 3: Che è un singolo codice. Un'impronta digitale. Se si modifica un solo account su un milione, l'impronta cambia totalmente.

24:06 Speaker 2: Quindi le applicazioni leggono i registri off- chain gratuiti. E quando vendi l'asset, il software ricostruisce il percorso matematico e fornisce al validatore la prova criptografica.

24:17 Speaker 3: Il validatore confronta la prova con la Merkle root salvata nella RAM. Se coincide, approva

24:23 Speaker 2: Il risultato economico è epocale. Abbattere questo peso fisico permette di portare il costo di emissione di un milione di asset da 24.000 token a tipo 5 o 10 token totali.

24:35 Speaker 3: Un calo del 99,9%. Questo ha sbloccato una categoria di infrastrutture del tutto nuova, i DEPIN.

24:43 Speaker 2: I DEPIN, le reti di infrastrutture fisiche decentralizzate, coordinano la costruzione e la manutenzione di hardware reale, antenne, server, pagando chi fornisce risorse.

24:56 Speaker 3: La critica solita alle blockchain è che non ci sono casi d'uso concreti fuori dalla speculazione finanziaria.

25:01 Speaker 2: I DEPIN sono la risposta. Ma per coordinare l'hardware, il sistema deve erogare di continuo micropagamenti. Se tu guidi per mappare una strada, ti devo pagare frazioni di centesimo al chilometro.

25:14 Speaker 3: Serve una latenza sotto il secondo e commissioni microscopiche. Le architetture classiche sono fuori dai giochi.

25:19 Speaker 2: Il banco di prova è stato Helium, per esempio. Rete globale per l'Internet of Things e il 5G.

25:25 Speaker 3: I Dreamati comprano antenne, le mettono in casa e forniscono copertura in cambio di token. Con l'aumento del traffico, la loro blockchain proprietaria è diventata un incubo.

25:35 Speaker 2: Quindi hanno abbandonato la loro blockchain e sono migrati interamente su questa infrastruttura monolitica.

25:42 Speaker 3: Delegando tutto il calcolo del consenso per concentrarsi sul loro core business. Un altro caso clamoroso è Hive Mapper.

25:51 Speaker 2: La mappatura stradale globale. Immaginiamo un passista. Mette una dashcam speciale sul cruscotto. E mentre fa le corse, mappa incroci e semafori.

26:01 Speaker 3: I dati vengono trasmessi e il registro valuta in pochi istanti l'accessione dell'immagine e il valore di quei dati.

26:08 Speaker 2: E in tempo reale, prima che il tassista arrivi al semaforo successivo, riceve nel suo wallet i micropagamenti in token.

26:16 Speaker 3: O pensiamo a Render Network e Io. net.

26:19 Speaker 2: Questi risolvono il problema delle risorse inattive aggregando potenza di calcolo delle GPU domestiche o delle server farm. C'è un'industria disperata per questa potenza. Modelli di intelligenza artificiale, studi di rendering tridimensionale.

26:35 Speaker 3: E la rete fa abbastanza di compensazione. Prende la potenza latente, l'affitta e regola i pagamenti al volo a costi microscopici.

26:42 Speaker 2: E qui arriviamo al punto critico. Abbiamo una macchina computazionale formidabile che fa girare telecomunicazioni mondiali e mercatia.

26:51 Speaker 3: Ma più diventi cruciale, più ti esponi a rischi sistemici devastanti.

26:55 Speaker 2: Qual è il tallone ad Achille di questo monolite perfetto?

26:58 Speaker 3: Paradossalmente il software.

26:59 Speaker 2: Se decine di migliaia di computer dipendono dallo stesso identico client software...

27:04 Speaker 3: Quello originario di Solana Labs o Ragave.

27:07 Speaker 2: Esatto, si crea il single point of failure.

27:10 Speaker 3: La mancanza di client diversity. Se un bug fatale nel codice di Agave sfugge agli audit ed entra in produzione, tutti i validatori andranno in crash simultaneamente nello stesso esatto millisecondo.

27:20 Speaker 2: La rete smette di produrre blocchi. Il tempo si ferma. Per scongiurare questo scenario apocalittico è intervenuta un'entità della finanza tradizionale. Jump Crypto.

27:32 Speaker 3: Hanno avviato un progetto di ingegneria monumentale chiamato Fire Dancer.

27:37 Speaker 2: E Firedancer non è una patch, non è un aggiornamento per tappare i buchi. È una riscrittura totale del software del validatore, da un foglio bianco.

27:46 Speaker 3: In linguaggio C e C + +, ma soprattutto applicando i dogmi dell'high frequency trading di Wall Street.

27:52 Speaker 2: E nel trading ad alta frequenza, le fortune evaporano in frazioni di microsecondo. Ogni ciclo di processore perso è un costo inaccettabile.

28:01 Speaker 3: Firedancer porta quest'ossessione nella blockchain. La manovra più aggressiva riguarda il rapporto con il sistema operativo.

28:08 Speaker 2: Questa cosa mi fa impazzire. Cioè, bypassano il sistema operativo? Se io installo Linux su un server, il software ignora il sistema operativo?

28:18 Speaker 3: Esatto, si chiama kernel bypass. Di solito, quando un pacchetto arriva alla scheda di rete, il kernel di Linux lo legge, fa i controlli e poi lo passa all'applicazione.

28:28 Speaker 2: Che crea un ritardo?

28:30 Speaker 3: Attrito di astrazione, sì. Microsecondi di ritardo che si accumulano e ti distruggono quando devi processare gigabyte di traffico globale.

28:38 Speaker 2: FireDancer aggira le chiamate al sistema operativo, insegna al software a pescare i dati crudi direttamente dai registri della scheda di rete fisica appena arrivano.

28:47 Speaker 3: Elimina l'intermediario burocratico e lascia che la CPU pensi solo all'esecuzione dei contratti. Inoltre isola tutte le funzioni in sandbox rigidissime, così se una viene compromessa le altre sono salve.

28:59 Speaker 2: Ma sostituire il motore di un aereo in volo non si fa dall'oggi al domani. Hanno usato una fase ibrida chiamata Frankendancer.

29:07 Speaker 3: Hanno incollato il nuovo motore di rete mostruoso di Firedancer al vecchio motore di consenso di Agave per testarne la stabilità sotto il fuoco vero.

29:16 Speaker 2: E l'installazione su scala globale del Firedancer completo ha un impatto vitale. Se un domani Agave va in crash per un bug, i nodi con Firedancer non se ne accorgono nemmeno.

29:28 Speaker 3: perché hanno una base di codice totalmente indipendente. Continueranno a produrre blocchi e garantire la finalità del sistema, immunità di gregge dall'ischio software.

29:37 Speaker 2: E oltre alla sicurezza, c'è l'esplosione. delle prestazioni. I test di FireDancer mostrano che elimina l'attrito del sistema operativo e satura fisicamente i limiti hardware delle macchine.

29:50 Speaker 3: Spingendo la rete a centinaia di migliaia di transazioni al secondo.

29:54 Speaker 2: portando la latenza a livelli superiori a molte infrastrutture chiuse dei mercati azionari mondiali. Che ci porta a tirare le fila di questa lunga analisi tecnica? Abbiamo esaminato un'architettura che ha affrontato il trilemma, smontandolo a livello atomico. La Proof of History ha strappato il tempo al caos. Il Tower BFT e Turbine gestiscono i dati senza intasare nulla.

30:18 Speaker 3: Gulfstream ha piallato la Mempool e le attese.

30:23 Speaker 2: E C- Level spreme il calcolo parallelo dai core delle CPU. Con la tokenomics disinflazionistica e l'affitto dello Stato a prevenire il degrado della RAM. Tutto questo ha permesso di comprimere i costi off- chain tramite radici di Merkle e ha abilitato l'esistenza globale dei D- PIN. E Firedancer promette di abbattere anche il tetto del software.

30:44 Speaker 3: Se si osserva l'itera traiettoria, si giunge a una riflessione macroeconomica incredibile. Se un'infrastruttura pubblica, decentralizzata, minazza di superare per latenza operativa e sicurezza strutturale le architetture chiuse dei massimi sistemi finanziari, quali scuse tecniche rimangono alla finanza istituzionale contemporanea per non decidere di migrare l'intera impalcatura dei mercati globali su un registro distribuito aperto?

31:10 Speaker 2: Seguite due pagine e lasciate una recensione a 5 stelle se questo approfondimento vi è stato utile.