“Tra 3 e 5 anni, RISC-V sarà ovunque!”

Il 2 marzo, alla prima conferenza ecologica Xuantie RISC-V tenuta da Ali Pingtou, David Patterson, il padre di RISC-V e vincitore del Premio Turing, ha affermato con sicurezza.
Dalla sua introduzione su 10 miliardi di processori, l'architettura x86 di Intel ha impiegato decenni, ARM 17 anni e RISC-V solo circa 10 anni, un risultato senza precedenti nella storia dello sviluppo dell'architettura dei chip.
Alcuni dati prevedono che entro il 2025 il numero di processori che utilizzeranno l’architettura RISC-V supererà gli 80 miliardi e nel campo dell’IoT si prevede che il 28% del mercato sarà occupato da RISC-V entro il 2025.
Allora, cos'è RISC-V? (I seguenti contenuti provengono principalmente dalla serie di articoli "La nascita di CKB-VM")
Introduzione a RISC-V
RISC-V è un'architettura di set di istruzioni CPU chiara, semplice e open source, nata presso l'Università della California, Berkeley.
Nel 2010, a causa delle limitazioni di altri set di istruzioni commerciali closed-source, un gruppo di ricerca della scuola ha progettato da zero un nuovo set di istruzioni open source quando ha iniziato un nuovo progetto. Questo nuovo set di istruzioni ha un gran numero di registri e una velocità di esecuzione delle istruzioni trasparente, che può aiutare i compilatori e i programmatori del linguaggio assembly a convertire problemi pratici e importanti in codice appropriato ed efficiente e contiene meno di 50 istruzioni.
Questo set di istruzioni è RISC-V, quindi RISC-V è un set di istruzioni molto giovane.
Quindi, quali sono i principali set di istruzioni prima di questo?
Nell'era del PC, x86 è il signore incrollabile. x86 è un CISC (Compless Instruction Set Computer), che è diverso dal RISC (Reduced Instruction Set Computer). Il numero di set di istruzioni CISC continua ad aumentare con lo sviluppo. Ciò farà sì che i costi continuino ad aumentare e anche le prestazioni e il consumo energetico ne risentiranno. Inoltre, la lunghezza del set di istruzioni CISC e il tempo di esecuzione non sono fissi, rendendo difficile trovare un percorso di progettazione universale efficiente per completare l'esecuzione delle istruzioni.
Dopo la popolarità degli smartphone, ARM è diventato il beniamino dei terminali mobili. ARM è un set di istruzioni ridotto (RISC) con basso consumo energetico e basso costo. Tuttavia, per mantenere la compatibilità con le versioni precedenti, ARM deve mantenere molte definizioni obsolete, con conseguente grave ridondanza del set di istruzioni, il che rende complessa la documentazione dell'architettura ARM sempre più alto.
Nell'attuale monopolio di x86 e ARM, RISC-V ha portato nuova vitalità al mercato.
L'obiettivo di RISC-V è fornire un'architettura comune del set di istruzioni della CPU per supportare lo sviluppo di architetture di sistema di prossima generazione senza il peso dei problemi architettonici legacy per i decenni a venire.
RISC-V è in grado di soddisfare i requisiti di implementazione, dai piccoli microprocessori a basso consumo ai processori per data center (DC) ad alte prestazioni. Rispetto ad altri set di istruzioni della CPU, il set di istruzioni RISC-V presenta i seguenti vantaggi:
Trasparenza (open source)
ARM e x86 sono entrambi progetti closed source e i termini di licenza sono estremamente rigidi: Intel non consente a nessuna azienda tranne AMD e VIA di utilizzare il set di istruzioni x86. Ottenere una licenza per il set di istruzioni ARM potrebbe richiedere decine di milioni di dollari Verranno addebitate tariffe di licenza e l'autorizzazione dovrà essere rinegoziata dopo la scadenza.
RISC-V è un vero progetto open source, noto come Linux in campo hardware. Infatti, l'intenzione originale del professor David Patterson, del professor Krste Asanovic, Andrew Waterman e Yunsup Lee che hanno inventato RISC-V era quella di "I set di istruzioni vogliono essere liberi", e qualsiasi azienda, università, istituto di ricerca e individuo in tutto il mondo può sviluppare processori compatibili con RISC con il set di istruzioni -V può essere integrato nell'ecosistema software e hardware costruito su RISC-V.
RISC-V utilizza l'accordo open source di licenza BSD (uno degli accordi di licenza più utilizzati nel software libero). L'accordo open source BSD consente agli utenti di modificare e ridistribuire il codice open source e consente anche lo sviluppo e la vendita di software commerciale basato. sul codice open source e può creare nuovo software/hardware senza restrizioni.
semplicità
Dopo decenni di sviluppo, i documenti dell'architettura x86 e ARM hanno raggiunto migliaia di pagine, la cui lettura richiede quasi un mese a un ingegnere, mentre la lettura dei documenti RISC-V richiede solo 1 o 2 giorni.
Questo perché RISC-V seleziona solo i set di istruzioni più comunemente utilizzati e poi li ottimizza in modo specifico. Per quanto riguarda le istruzioni non comuni, queste possono essere completate combinando diverse istruzioni di base, il che può migliorare notevolmente l'efficienza. Pertanto, partendo dal presupposto di fornire le stesse funzioni, il set di istruzioni RISC-V è più facile da implementare e può evitare bug rispetto al set di istruzioni x86 con migliaia di istruzioni.
Ad esempio, se utilizziamo x86, dobbiamo acquistare un intero supermercato per usufruire degli articoli di cui abbiamo bisogno; ma RISC-V è un supermercato in cui è possibile acquistare gli articoli singolarmente e i clienti devono scegliere solo gli articoli di cui hanno bisogno basta pagare per questo.
Modulare
RISC-V utilizza un nucleo semplificato e utilizza un meccanismo modulare per fornire impostazioni di set di istruzioni più estese.
ampiezza del sostegno
Compilatori come GCC e LLVM supportano il set di istruzioni RISC-V e anche il backend di Go per RISC-V è in fase di sviluppo.
scadenza
Il set di istruzioni principali di RISC-V è stato finalmente confermato e corretto e tutte le future implementazioni di RISC-V devono essere compatibili con le versioni precedenti. Inoltre, il set di istruzioni RISC-V è stato implementato nell'hardware ed è stato verificato in scenari applicativi reali e non esistono rischi potenziali esistenti in altri set di istruzioni con supporto inferiore.
Quando CKB-VM incontra RISC-V
CKB è il livello base di Nervos Network e il suo obiettivo è fornire sicurezza e decentralizzazione sufficienti per le applicazioni di livello superiore. Nel processo di ricerca e selezione di CKB-VM, abbiamo pensato ripetutamente a: quali caratteristiche dovrebbe avere CKB-VM?
Ovviamente, affinché una macchina virtuale possa essere utilizzata su una blockchain, ci sono due caratteristiche chiave che devono essere rispettate in ogni caso:
1. Determinismo: per programmi e input fissi, la macchina virtuale deve sempre restituire risultati di output fissi e i risultati non cambieranno a causa del tempo, dell'ambiente operativo e di altre condizioni esterne;
2. Sicurezza: l'esecuzione di una macchina virtuale non influirà sul funzionamento della piattaforma stessa.
Ma queste condizioni sono solo obbligatorie e speriamo di progettare una macchina virtuale che possa servire meglio gli obiettivi di CKB. Dopo un'attenta considerazione, riteniamo che tale macchina virtuale dovrebbe soddisfare le seguenti caratteristiche:
flessibilità
Il nostro obiettivo è progettare una macchina virtuale che sia sufficientemente flessibile da funzionare a lungo in modo che CKB possa tenere il passo con lo sviluppo della crittografia. La storia della crittografia è un'eterna battaglia tra "impugnare la spada" e "rompere il muro": nella storia dello sviluppo della crittografia da migliaia di anni, crittografia e decrittografia sono una competizione intellettuale senza fine sarà lo stesso in futuro. Alcuni algoritmi di crittografia adatti oggi, come secp256k1, potrebbero essere obsoleti in futuro. Nuovi algoritmi e tecnologie più preziosi (come Schnorr o firme post-quantiche, ecc.) continueranno ad emergere in futuro. I programmi in esecuzione sulla macchina virtuale della blockchain dovrebbero essere in grado di utilizzare nuovi algoritmi in modo più libero e conveniente e, allo stesso tempo, quegli algoritmi obsoleti dovrebbero essere naturalmente eliminati.
Per facilitare la comprensione, usiamo Bitcoin come esempio. Attualmente, Bitcoin utilizza SIGHASH per le firme delle transazioni e utilizza l'algoritmo di hashing SHA-256 nel protocollo di consenso. Possiamo quindi garantire che questo approccio SIGHASH utilizzato da Bitcoin sarà ancora la scelta migliore tra qualche anno? Oppure, con l’aumento della potenza di calcolo, SHA-256 è ancora adatto come algoritmo hash stabile? Per tutti i protocolli blockchain che stiamo attualmente studiando, se è necessario aggiornare l’algoritmo di crittografia, sarà inevitabilmente necessario un hard fork. Durante la progettazione di CKB, volevamo esplorare come ridurre la possibilità di hard fork attraverso la progettazione della VM.
Stiamo pensando, la macchina virtuale può consentire l'aggiornamento dell'algoritmo di crittografia? Oppure è possibile aggiungere una nuova logica di convalida delle transazioni alla VM? Ad esempio, pur utilizzando secp256k1, se ci sono incentivi economici o è necessario aggiornare l’algoritmo, possiamo implementare un algoritmo di verifica della firma più efficiente senza biforcarsi? Oppure, se qualcuno trova un modo per implementare un algoritmo migliore su CKB, o ha bisogno di introdurre un nuovo algoritmo di crittografia, possiamo garantire che possa implementarlo liberamente?
Ci auguriamo che CKB-VM possa fornire a tutti più spazio di implementazione, massimizzare la flessibilità e consentire agli utenti di utilizzare nuovi algoritmi di crittografia senza attendere hard fork.
trasparenza operativa
Dopo aver studiato l’attuale generazione di VM blockchain, abbiamo notato un problema, prendendo ancora Bitcoin come esempio: il livello VM di Bitcoin fornisce solo uno stack e lo stack non può sapere cosa può essere memorizzato nello stack durante l’esecuzione , è lo stesso problema per tutte le altre VM implementate in modalità stack, sebbene il livello di consenso possa fornire una definizione di profondità dello stack o fornire la profondità dello stack indirettamente (in base alla lunghezza delle istruzioni o ai limiti di gas). Ciò costringerà gli sviluppatori del programma sulla VM a indovinare lo stato del programma quando è in esecuzione. Questo tipo di VM impedisce al programma di sfruttare appieno il pieno potenziale della VM.
Sulla base di questo problema, riteniamo che dovrebbe essere una priorità definire i limiti di tutte le risorse durante il funzionamento della VM, inclusi i limiti di gas e le dimensioni dello spazio dello stack, e consentire ai programmi in esecuzione sulla VM di interrogare l'utilizzo delle risorse. Ciò consentirà ai programmi in esecuzione la VM viene impiegata in diversi algoritmi in base alla disponibilità delle risorse. Con questo design, i programmi possono sfruttare tutto il potenziale della VM. E nei seguenti scenari, possiamo vedere una maggiore flessibilità della VM:
1. Puoi scegliere diverse strategie per i contratti intelligenti che memorizzano i dati in base allo spazio di archiviazione (capacità della cella) disponibile per gli utenti su CKB. Quando la capacità della cella è sufficiente, il programma può memorizzare direttamente i dati per ridurre il numero di cicli della CPU utilizzati (i passaggi che la CPU esegue per eseguire un'istruzione macchina); quando la capacità della cella è limitata, il programma può comprimere i dati per adattarsi alla capacità minore e utilizzare più cicli CPU.
2. È possibile selezionare diversi meccanismi di elaborazione per il contratto intelligente in base alla quantità totale di dati (Cell Data) archiviati dall'utente e alla dimensione della memoria rimanente. Quando è presente una piccola quantità di dati della cella o una grande quantità di memoria rimanente, tutti i dati della cella possono essere letti in memoria per l'elaborazione. Quando è presente una grande quantità di dati della cella o poca memoria rimanente, ciascuna operazione può leggere solo parte della memoria, in modo simile all'operazione di scambio della memoria.
3. Per alcuni contratti comuni, come gli algoritmi hash, è possibile selezionare diversi metodi di elaborazione in base al numero di cicli CPU forniti dall'utente. Ad esempio, la sicurezza di SHA3-256 è sufficiente per soddisfare le esigenze della maggior parte degli scenari, tuttavia, il contratto può utilizzare l'algoritmo SHA3-512 per soddisfare requisiti di sicurezza più elevati utilizzando più cicli della CPU.
Sovraccarico di esecuzione
Il meccanismo Gas nella Ethereum Virtual Machine (EVM) è un design davvero geniale. Risolve elegantemente il problema di spegnimento negli scenari di applicazione blockchain (poiché Ethereum è Turing completo, sono consentite istruzioni di loop, ma le istruzioni di loop infinite possono facilmente causare problemi di spegnimento). Il meccanismo del gas limita la quantità massima di calcolo di un blocco, evitando così questo problema) e consentendo al programma di eseguire calcoli su una macchina virtuale completamente decentralizzata. Tuttavia, abbiamo riscontrato che è molto difficile progettare un metodo di calcolo del gas ragionevole per diversi Opcode (operatori) in EVM. EVM deve adattare il meccanismo di calcolo del gas quasi ogni volta che viene aggiornato (il livello di astrazione di EVM è relativamente più alto, uno). L'istruzione EVM può corrispondere a diverse istruzioni hardware sottostanti Durante l'esecuzione del programma, la quantità di dati elaborati e la complessità computazionale possono essere valutate solo tramite stima, quindi l'EVM deve adeguare continuamente il meccanismo di calcolo del gas.
Pertanto, ci siamo chiesti: è possibile utilizzare la progettazione della VM per garantire che il metodo di calcolo del consumo di risorse quando il programma è in esecuzione sia più ragionevole e accurato?
Speravamo di trovare un progetto di VM che fornisse tutte le funzionalità di cui sopra, ma abbiamo scoperto che non esisteva una soluzione standard in grado di realizzare la nostra visione di CKB. Pertanto, abbiamo deciso di riprogettare una VM che potesse soddisfare tutte le caratteristiche di cui sopra per realizzare al meglio la visione di CKB.
Sebbene altri set di istruzioni possano condividere alcune di queste funzionalità, nella nostra valutazione il set di istruzioni RISC-V è l'unico a averle tutte.
Pertanto, alla fine abbiamo scelto di implementare CKB-VM utilizzando il set di istruzioni RISC-V.
Lettura consigliata:
1. Dopo aver aspettato e osservato, tastato il terreno e incappato in trappole, RISC-V è salito sul trampolino di lancio per entrare nell'età dell'oro.
2. RISC-V è davvero diventato una realtà e la velocità è un po' oltre ogni immaginazione.
3. Quando CKB-VM incontra RISC-V——La nascita di CKB-VM
https://talk.nervos.org/t/ckb-vm-risc-v-ckb-vm/1667
4. La nascita di CKB-VM, una macchina virtuale blockchain basata su RISC-V (1)
https://talk.nervos.org/t/risc-v-ckb-vm/1726
5. Ispirazione, design e vantaggi: la nascita di CKB-VM (2)
https://talk.nervos.org/t/ckb-vm/1730
6. Come giocare allegramente su CKB-VM - La nascita di CKB-VM (3)
https://talk.nervos.org/t/ckb-vm-ckb-vm/1765
7. La domanda fondamentale di Zaki Manian: macchina virtuale Blockchain, quale è più adatta, WASM o RISC-V?
https://talk.nervos.org/t/zaki-manian-wasm-risc-v/463