„In 3 bis 5 Jahren wird RISC-V überall sein!“

Am 2. März äußerte sich David Patterson, der Vater von RISC-V und Turing-Award-Gewinner, auf der ersten Xuantie RISC-V Ecological Conference, die von Ali Pingtou abgehalten wurde, zuversichtlich.
Von der Einführung bis hin zu 10 Milliarden Prozessoren hat die x86-Architektur von Intel Jahrzehnte gedauert, ARM 17 Jahre und RISC-V nur etwa 10 Jahre, was in der Geschichte der Entwicklung der Chiparchitektur beispiellos ist.
Einige Daten gehen davon aus, dass die Zahl der Prozessoren, die die RISC-V-Architektur verwenden, bis 2025 80 Milliarden überschreiten wird. Im IoT-Bereich wird vorhergesagt, dass RISC-V bis 2025 28 % des Marktes einnehmen wird.
Was ist also RISC-V? (Der folgende Inhalt stammt hauptsächlich aus der Artikelserie „Die Geburt von CKB-VM“)
Einführung in RISC-V
RISC-V ist eine klare, einfache Open-Source-CPU-Befehlssatzarchitektur, die an der University of California in Berkeley entwickelt wurde.
Aufgrund der Einschränkungen anderer kommerzieller Closed-Source-Anweisungssätze entwarf ein Forschungsteam der Schule im Jahr 2010 zu Beginn eines neuen Projekts einen neuen Open-Source-Anweisungssatz von Grund auf. Dieser neue Befehlssatz verfügt über eine große Anzahl von Registern und eine transparente Befehlsausführungsgeschwindigkeit, die Compilern und Assemblerprogrammierern dabei helfen kann, praktische und wichtige Probleme in geeigneten, effizienten Code umzuwandeln, und enthält weniger als 50 Befehle.
Dieser Befehlssatz ist RISC-V, daher ist RISC-V ein sehr junger Befehlssatz.
Was sind also die wichtigsten Befehlssätze davor?
Im PC-Zeitalter ist x86 der unerschütterliche Herrscher. x86 ist ein CISC (Complex Instruction Set Computer), der sich von RISC (Reduced Instruction Set Computer) unterscheidet. Die Anzahl der CISC-Befehlssätze nimmt mit der Entwicklung weiter zu. Dadurch werden die Kosten weiter steigen und auch Leistung und Stromverbrauch werden beeinträchtigt. Darüber hinaus sind die Länge des CISC-Befehlssatzes und die Ausführungszeit nicht festgelegt, was es schwierig macht, einen effizienten universellen Entwurfspfad zur Vervollständigung der Befehlsausführung zu finden.
Nach der Popularität von Smartphones ist ARM zum Liebling des mobilen Endgeräts geworden. ARM ist ein reduzierter Befehlssatz (RISC) mit geringem Stromverbrauch und geringen Kosten. Um die Abwärtskompatibilität aufrechtzuerhalten, muss ARM jedoch viele veraltete Definitionen beibehalten, was zu einer erheblichen Redundanz des Befehlssatzes führt, was die Dokumentation der ARM-Architektur immer komplexer macht höher und höher.
Im derzeitigen Monopol von x86 und ARM hat RISC-V dem Markt neue Dynamik verliehen.
Das Ziel von RISC-V besteht darin, eine gemeinsame CPU-Befehlssatzarchitektur bereitzustellen, um die Entwicklung von Systemarchitekturen der nächsten Generation zu unterstützen, ohne dass in den kommenden Jahrzehnten die Belastung durch alte Architekturprobleme entsteht.
RISC-V kann die Implementierungsanforderungen von kleinen Mikroprozessoren mit geringem Stromverbrauch bis hin zu leistungsstarken Rechenzentrumsprozessoren (DC) erfüllen. Im Vergleich zu anderen CPU-Befehlssätzen bietet der RISC-V-Befehlssatz die folgenden Vorteile:
Transparenz (Open Source)
ARM und x86 sind beide Closed-Source-Projekte, und die Lizenzbedingungen sind äußerst streng: Intel erlaubt keinem Unternehmen außer AMD und VIA, den x86-Befehlssatz zu verwenden, um eine Lizenz für den ARM-Befehlssatz zu erhalten Es werden Lizenzgebühren erhoben und die Autorisierung muss nach Ablauf der Autorisierung neu ausgehandelt werden.
RISC-V ist ein echtes Open-Source-Projekt, im Hardwarebereich als Linux bekannt. Tatsächlich war die ursprüngliche Absicht von Professor David Patterson, Professor Krste Asanovic, Andrew Waterman und Yunsup Lee, die RISC-V erfunden haben, „Befehlssätze wollen frei sein“, und jedes Unternehmen, jede Universität, jede Forschungseinrichtung und jeder Einzelne auf der ganzen Welt kann dies tun Entwickeln Sie RISC-kompatible Prozessoren mit dem Befehlssatz -V, die in das auf RISC-V basierende Software- und Hardware-Ökosystem integriert werden können.
RISC-V verwendet die BSD-Lizenz-Open-Source-Vereinbarung (eine der am weitesten verbreiteten Lizenzvereinbarungen für freie Software). Die BSD-Open-Source-Vereinbarung ermöglicht Benutzern die Änderung und Weiterverbreitung von Open-Source-Code sowie die Entwicklung und den Verkauf kommerzieller Software auf Open-Source-Code und können ohne Einschränkungen neue Software/Hardware erstellen.
Einfachheit
Nach jahrzehntelanger Entwicklung haben die Architekturdokumente von x86 und ARM Tausende von Seiten erreicht, für deren Lektüre ein Ingenieur fast einen Monat braucht, während das Lesen von RISC-V-Dokumenten nur 1 bis 2 Tage dauert.
Dies liegt daran, dass RISC-V nur die am häufigsten verwendeten Befehlssätze auswählt und diese dann gezielt optimiert. Ungewöhnliche Befehle können durch die Kombination mehrerer grundlegender Befehle vervollständigt werden, was die Effizienz erheblich verbessern kann. Daher ist der RISC-V-Befehlssatz unter der Voraussetzung, dass er die gleichen Funktionen bereitstellt, einfacher zu implementieren und kann Fehler vermeiden als der x86-Befehlssatz mit Tausenden von Befehlen.
Wenn wir beispielsweise x86 verwenden, müssen wir einen ganzen Supermarkt kaufen, um die Artikel zu erhalten, die wir benötigen. RISC-V ist jedoch ein Supermarkt, in dem Sie Artikel einzeln kaufen können und die Kunden nur die Artikel auswählen müssen, die sie benötigen Bezahlen Sie einfach dafür.
Modular
RISC-V verwendet einen vereinfachten Kern und einen modularen Mechanismus, um erweiterte Befehlssatzeinstellungen bereitzustellen.
Umfang der Unterstützung
Compiler wie GCC und LLVM unterstützen den RISC-V-Befehlssatz, und Gos Backend für RISC-V befindet sich ebenfalls in der Entwicklung.
Reife
Der RISC-V-Kernbefehlssatz wurde endgültig bestätigt und korrigiert, und alle zukünftigen RISC-V-Implementierungen müssen abwärtskompatibel sein. Darüber hinaus wurde der RISC-V-Befehlssatz in Hardware implementiert und in realen Anwendungsszenarien verifiziert, und es bestehen keine potenziellen Risiken, die bei anderen Befehlssätzen mit geringerer Unterstützung bestehen.
Wenn CKB-VM auf RISC-V trifft
CKB ist die Basisschicht des Nervos-Netzwerks und ihr Ziel besteht darin, ausreichende Sicherheit und Dezentralisierung für Anwendungen der oberen Schicht bereitzustellen. Bei der Recherche und Auswahl von CKB-VM haben wir immer wieder darüber nachgedacht: Welche Funktionen sollte CKB-VM haben?
Damit eine virtuelle Maschine auf einer Blockchain eingesetzt werden kann, müssen natürlich in jedem Fall zwei wesentliche Eigenschaften erfüllt sein:
1. Determinismus: Für feste Programme und Eingaben muss die virtuelle Maschine immer feste Ausgabeergebnisse zurückgeben, und die Ergebnisse ändern sich nicht aufgrund von Zeit, Betriebsumgebung und anderen externen Bedingungen.
2. Sicherheit: Die Ausführung einer virtuellen Maschine hat keinen Einfluss auf den Betrieb der Plattform selbst.
Diese Bedingungen sind jedoch nur zwingend erforderlich, und wir hoffen, eine virtuelle Maschine entwerfen zu können, die den Zielen von CKB besser dienen kann. Nach sorgfältiger Überlegung sind wir der Meinung, dass eine solche virtuelle Maschine die folgenden Eigenschaften erfüllen sollte:
Flexibilität
Unser Ziel ist es, eine virtuelle Maschine zu entwerfen, die flexibel genug ist, um über einen langen Zeitraum betrieben zu werden, damit CKB mit der Entwicklung der Kryptographie Schritt halten kann. Die Geschichte der Kryptographie ist ein ewiger Kampf zwischen „das Schwert halten“ und „die Mauer durchbrechen“: In der jahrtausendealten Geschichte der Kryptographie sind Verschlüsselung und Entschlüsselung ein endloser intellektueller Wettbewerb wird auch in Zukunft das Gleiche sein. Einige Verschlüsselungsalgorithmen, die für heute geeignet sind, wie etwa secp256k1, könnten in Zukunft veraltet sein; wertvollere neue Algorithmen und Technologien (wie etwa Schnorr oder Post-Quantum-Signaturen usw.) werden auch in Zukunft auftauchen. Programme, die auf der virtuellen Maschine der Blockchain laufen, sollten in der Lage sein, neue Algorithmen freier und bequemer zu nutzen, und gleichzeitig sollten diese veralteten Algorithmen auf natürliche Weise eliminiert werden.
Um das Verständnis zu erleichtern, verwenden wir Bitcoin als Beispiel. Derzeit verwendet Bitcoin SIGHASH für Transaktionssignaturen und den SHA-256-Hashing-Algorithmus im Konsensprotokoll. Können wir also sicherstellen, dass dieser von Bitcoin verwendete SIGHASH-Ansatz auch in ein paar Jahren noch die beste Wahl sein wird? Oder eignet sich SHA-256 mit steigender Rechenleistung noch als stabiler Hash-Algorithmus? Für alle Blockchain-Protokolle, die wir derzeit untersuchen, ist zwangsläufig ein Hard Fork erforderlich, wenn der Verschlüsselungsalgorithmus aktualisiert werden muss. Beim Design von CKB wollten wir untersuchen, wie wir die Möglichkeit von Hard Forks durch das Design der VM reduzieren können.
Wir fragen uns: Kann die virtuelle Maschine ein Upgrade des Verschlüsselungsalgorithmus ermöglichen? Oder ist es möglich, der VM eine neue Transaktionsvalidierungslogik hinzuzufügen? Können wir beispielsweise bei weiterhin Verwendung von secp256k1 einen effizienteren Signaturverifizierungsalgorithmus ohne Fork implementieren, wenn es wirtschaftliche Anreize gibt oder eine Aktualisierung des Algorithmus erforderlich ist? Oder wenn jemand einen Weg findet, einen besseren Algorithmus auf CKB zu implementieren, oder einen neuen Verschlüsselungsalgorithmus einführen muss, können wir dann sicherstellen, dass er/sie diesen frei implementieren kann?
Wir hoffen, dass CKB-VM jedem mehr Implementierungsraum bieten, die Flexibilität maximieren und Benutzern die Verwendung neuer Verschlüsselungsalgorithmen ermöglichen kann, ohne auf Hard Forks warten zu müssen.
betriebliche Transparenz
Nachdem wir die aktuelle Generation von Blockchain-VMs untersucht hatten, stellten wir am Beispiel von Bitcoin ein Problem fest: Die VM-Schicht von Bitcoin stellt nur einen Stapel bereit, und der Stapel kann nicht wissen, welche Datengröße oder Stapeltiefe während der Ausführung auf dem Stapel gespeichert werden kann , ist das gleiche Problem für alle anderen VMs, die im Stack-Modus implementiert sind, obwohl die Konsensschicht eine Definition der Stack-Tiefe bereitstellen oder die Stack-Tiefe indirekt bereitstellen kann (basierend auf Befehlslänge oder Gaslimits). Dadurch werden Programmentwickler auf der VM gezwungen, den Status des Programms zu erraten, wenn es ausgeführt wird. Diese Art von VM verhindert, dass das Programm das volle Potenzial der VM ausschöpft.
Aufgrund dieses Problems glauben wir, dass es eine Priorität sein sollte, die Grenzen aller Ressourcen während des VM-Betriebs zu definieren, einschließlich Gasgrenzen und Stapelspeichergröße, und es Programmen zu ermöglichen, die auf der VM ausgeführt werden, um die Ressourcennutzung abzufragen Je nach Ressourcenverfügbarkeit werden unterschiedliche Algorithmen eingesetzt. Mit diesem Design können Programme das volle Potenzial der VM ausschöpfen. Und in den folgenden Szenarien können wir mehr Flexibilität von VM sehen:
1. Sie können verschiedene Strategien für Smart Contracts wählen, die Daten basierend auf dem Speicherplatz (Zellenkapazität) speichern, der Benutzern auf CKB zur Verfügung steht. Wenn die Zellenkapazität ausreichend ist, kann das Programm Daten direkt speichern, um die Anzahl der verwendeten CPU-Zyklen zu reduzieren (die Schritte, die die CPU zur Ausführung eines Maschinenbefehls durchführt). Wenn die Zellenkapazität begrenzt ist, kann das Programm die Daten zur Anpassung komprimieren auf die kleinere Kapazität und nutzen mehr CPU-Zyklen.
2. Für den Smart Contract können verschiedene Verarbeitungsmechanismen ausgewählt werden, basierend auf der Gesamtmenge der vom Benutzer gespeicherten Daten (Cell Data) und der Größe des verbleibenden Speichers. Wenn eine kleine Menge an Zelldaten oder eine große Menge an verbleibendem Speicher vorhanden ist, können alle Zelldaten zur Verarbeitung in den Speicher eingelesen werden. Wenn eine große Menge an Zelldaten oder nur wenig verbleibender Speicher vorhanden ist, kann jeder Vorgang nur einen Teil des Speichers lesen, ähnlich wie beim Speicheraustauschvorgang.
3. Für einige gängige Verträge, wie z. B. Hash-Algorithmen, können unterschiedliche Verarbeitungsmethoden basierend auf der vom Benutzer bereitgestellten Anzahl von CPU-Zyklen ausgewählt werden. Beispielsweise reicht die Sicherheit von SHA3-256 aus, um die Anforderungen der meisten Szenarien zu erfüllen. Der Vertrag kann jedoch den SHA3-512-Algorithmus verwenden, um höhere Sicherheitsanforderungen zu erfüllen, indem mehr CPU-Zyklen verwendet werden.
Laufzeitaufwand
Der Gas-Mechanismus in der Ethereum Virtual Machine (EVM) ist ein sehr geniales Design. Er löst auf elegante Weise das Abschaltproblem in Blockchain-Anwendungsszenarien (da Ethereum Turing-vollständig ist, sind Schleifenanweisungen zulässig, aber Endlosschleifen-Anweisungen können leicht zu Abschaltproblemen führen.) Der Gasmechanismus begrenzt die maximale Berechnungsmenge eines Blocks und vermeidet so dieses Problem) und ermöglicht es dem Programm, Berechnungen auf einer vollständig dezentralisierten virtuellen Maschine durchzuführen. Wir haben jedoch festgestellt, dass es sehr schwierig ist, eine vernünftige Gasberechnungsmethode für verschiedene Opcodes (Operatoren) in EVM zu entwerfen. EVM muss den Gasberechnungsmechanismus fast jedes Mal anpassen, wenn er aktualisiert wird (die Abstraktionsebene von EVM ist relativ hoch). Der EVM-Befehl kann mehreren zugrunde liegenden Hardware-Befehlen entsprechen. Bei der Ausführung des Programms können die verarbeitete Datenmenge und die Rechenkomplexität nur durch Schätzung ermittelt werden, sodass der EVM den Gasberechnungsmechanismus kontinuierlich anpassen muss.
Daher haben wir uns gefragt: Kann das VM-Design verwendet werden, um sicherzustellen, dass die Berechnungsmethode für den Ressourcenverbrauch bei laufendem Programm vernünftiger und genauer ist?
Wir hofften, ein VM-Design zu finden, das alle oben genannten Funktionen bietet, stellten jedoch fest, dass es keine Standardlösung gab, mit der wir unsere Vision für CKB verwirklichen konnten. Aus diesem Grund haben wir uns entschieden, eine VM neu zu entwerfen, die alle oben genannten Eigenschaften erfüllen kann, um die Vision von CKB besser zu verwirklichen.
Während andere Befehlssätze einige dieser Funktionen möglicherweise gemeinsam haben, ist in unserer Bewertung der RISC-V-Befehlssatz der einzige, der über alle diese Funktionen verfügt.
Daher haben wir uns letztendlich für die Implementierung von CKB-VM mithilfe des RISC-V-Befehlssatzes entschieden.
Literatur-Empfehlungen:
1. Nach dem Warten und Beobachten, dem Testen des Wassers und dem Betreten von Fallstricken steht RISC-V auf dem Sprungbrett zum Eintritt in das goldene Zeitalter.
2. RISC-V ist wirklich Realität geworden, und die Geschwindigkeit ist etwas unvorstellbar.
3. Wenn CKB-VM auf RISC-V trifft – Die Geburt von CKB-VM
https://talk.nervos.org/t/ckb-vm-risc-v-ckb-vm/1667
4. Die Geburt von CKB-VM, einer virtuellen Blockchain-Maschine basierend auf RISC-V (1)
https://talk.nervos.org/t/risc-v-ckb-vm/1726
5. Inspiration, Design und Vorteile – die Geburt von CKB-VM (2)
https://talk.nervos.org/t/ckb-vm/1730
6. Wie man glücklich auf CKB-VM spielt – Die Geburt von CKB-VM (3)
https://talk.nervos.org/t/ckb-vm-ckb-vm/1765
7. Zaki Manians Kernfrage: Welche virtuelle Blockchain-Maschine ist besser geeignet, WASM oder RISC-V?
https://talk.nervos.org/t/zaki-manian-wasm-risc-v/463