Initialement publié en anglais par Sin7y Labs
Nous travaillons sur la construction du premier ZKVM basé sur une architecture d'exécution parallèle. Et visons à atteindre des TPS plus élevé grâce à l'amélioration d’une architecture compatible ZK et des algorithmes ZK. Les caractéristiques techniques sont les suivantes :
Génération de preuves rapide
Compatibilité ZK : circuit de plus petite échelle et unités de contrainte inférieure simplifiées
ZK rapide : optimisation supplémentaire sur Plonky2
Exécution rapide : utilisation de l'exécution parallèle pour réduire considérablement le temps de génération des preuves
Avancées actuelles :
En juillet 2022, nous avons publié le Livre blanc OlaVM.
En novembre 2022, nous avons achevé la conception et le développement du jeu d'instructions, et réalisé le module d'exécution OlaVM de la machine virtuelle. Vous pouvez consulter le lien : https://github.com/Sin7Y/olavm pour voir notre code qui est régulièrement mis à jour.
Pour l'algorithme ZK offrant la plus grande efficacité d'exécution, nous avons terminé la conception du circuit et la recherche d'algorithmes de Plonky2. Vous pouvez consulter le lien : https://github.com/Sin7Y/plonky2/tree/main/plonky2/designs pour en savoir plus sur la conception de Plonky2, nous allons l'optimiser et l'améliorer dans la prochaine étape. Restez à l'écoute.
OlaVM est le premier ZKVM à introduire l'exécution parallèle dans une machine virtuelle (VM). OlaVM intègre les caractéristiques techniques des deux schémas pour obtenir une vitesse d'exécution et une vitesse de preuve plus rapides, permettant d'atteindre le plus haut niveau TPS du système.
Il y a deux raisons principales pour lesquelles Ethereum a un faible débit de transaction:
Processus de consensus : chaque nœud exécute toutes les transactions de manière répétée afin de vérifier leur validité.
Exécution des transactions : l'exécution des transactions est mono-thread. Pour résoudre notre premier problème, tout en conservant la programmabilité, de nombreux projets ont mené des recherches sur des machines virtuelles dites zkEVM. C'est-à-dire que les transactions sont effectuées off-chain et seule la vérification de l'état est effectuée on-chain (bien sûr, il existe d'autres schémas d'extension de capacité, mais nous n'entrerons pas dans les détails dans cet article). Afin d’améliorer le débit du système, les preuves doivent être générées le plus rapidement possible. Pour résoudre notre deuxième problème, Aptos, Solona, Sui et d'autres nouvelles chaînes publiques ont introduit des machines virtuelles avec une exécution parallèle (PE-VM) (bien sûr, cela inclut également un mécanisme de consensus plus rapide) afin d’améliorer les TPS global du système.
À ce stade, pour les zkEVM, le goulot d'étranglement affectent les TPS de l'ensemble du système est la génération des preuves. Cependant, lorsque Parallel Prove est utilisé pour accélérer le débit, plus le bloc est généré rapidement, plus tôt commence la génération des preuves correspondante (avec l'évolution des algorithmes ZK et les progrès sur les moyens d'accélération, plus le temps de génération des preuves est court, plus l'amélioration apportée est efficace et significative).
L’augmentation de la vitesse de génération des preuves est l'aspect le plus important pour augmenter le débit global du système. Il existe deux moyens d'accélérer la génération des preuves : réduire au maximum la taille de votre circuit et utiliser un algorithme ZK le plus efficace possible. Vous décomposez davantage la signification d'un algorithme efficace, car cela peut se diviser en améliorant l'ajustement des paramètres tels que la sélection d'un champ plus petit, et d'autre part, l'amélioration de l'environnement d'exécution externe en utilisant du matériel spécifique afin d’optimiser et mettre à l'échelle la solution.
Réduire au maximum la taille de votre circuit
Comme décrit précédemment, le coût de génération des preuves est fortement lié à la taille totale de la contrainte n. Par conséquent, si vous parvenez à réduire considérablement la taille de la contrainte, votre temps de génération sera également considérablement réduit. Cela peut être réalisé en utilisant différents schémas de conception de manière astucieuse pour maintenir votre circuit aussi petit que possible.
Nous introduisons un module que nous appellerons "Prophet" Il existe de nombreuses définitions différentes d'un prophet, mais nous nous sommes concentrés sur "Prédire" puis "Vérifier". Le but principal de ce module est de nous permettre, étant donné un calcul complexe, de ne pas avoir à utiliser l'ensemble d'instructions de la machine virtuelle pour effectuer ces calculs. La raison en est que cela peut consommer beaucoup d'instructions, augmentant ainsi la trajectoire d'exécution de la machine virtuelle et la taille finale de la contrainte. En effet, c'est ici que le module Prophet entre en jeu, il s'agit d'un module intégré qui effectue le calcul pour nous, envoie les résultats à la machine virtuelle, qui effectuera une vérification de légitimité et vérifiera le résultat. Le Prophet est un ensemble de fonctions intégrées avec des fonctions de calcul spécifiques, telles que division, square root, cube root, etc. Nous enrichirons progressivement la bibliothèque des Prophets en fonction des scénarios réels pour maximiser l'effet global de réduction de contrainte pour la plupart des scénarios de calcul complexes.
Compatibilité ZK
En traitant les calculs complexes, le module Prophet peut nous aider à réduire la taille globale de la trace d'exécution des machines virtuelles, cependant, il serait pratique et préférable que les calculs eux-mêmes soient compatible ZK. Par conséquent, dans notre architecture, nous avons opté pour la conception d’une solution autour des opérations compatible ZK (choix des algorithmes de hachage, etc.), certaines de ces optimisations étant présentes dans d'autres zkEVMs également. En plus de la logique de calcul que la machine virtuelle exécute elle-même, il existe d'autres opérations qui doivent également être prouvées, telles que les opérations de RAM. Dans le cas d'une machine virtuelle stack-based, les opérations POP et PUSH doivent être exécutées à chaque accès. Au niveau de la vérification, il est toujours nécessaire de vérifier la validité de ces opérations. Elles formeront des tables indépendantes, puis utiliseront des contraintes pour vérifier la validité des opérations de la stack. En revanche, Register-based VMs, exécutant exactement la même logique, se traduisant par une trajectoire d'exécution plus petite et donc une échelle de contrainte réduite.
ZK Algorithmes & efficacité
Jusqu'à présent, les algorithmes ZK a réalisé des progrès remarquables en termes de faisabilité technique. Les scénarios deviennent de plus en plus généraux et efficaces, passant de R1CS à Plonkish, d'un champ plus grand tel que Cairo VM :
P = 2^251 + 17 * 2^192 + 1
à un champ plus petit (Plonky2) :
P = 2^64 - 2^32 + 1
On observe également une accélération de l'implémentation CPU vers GPU/FPGA/ASIC, tels que l’architecture accéléré FPGA par Ingonyama et l’architecture ASIC par Semisand, etc.
En raison des performances impressionnantes de Plonky2, nous utilisons temporairement Plonky2 comme un backend ZK d'OlaVM. Nous avons mené une analyse approfondie sur l’architecture Gate, architecture Gadget et des principes du protocole central de Plonky2, et identifié les domaines dans lesquels nous pouvons contribuer et améliorer davantage l'efficacité. Consultez notre Github : Plonky2 designs pour plus d'informations.
Exécution plus rapide des transactions (qui n’est actuellement pas un goulot d'étranglement à ce stade) Dans l’architecture d'OlaVM, le Prover n'est pas sous licence et n'importe qui peut y accéder. Ainsi, lorsque vous disposez de nombreux Provers, vous pouvez générer des preuves pour ces blocs en parallèle, puis agréger ces preuves ensemble et les soumettre à la chaîne pour être vérifié. Étant donné que le module Prover s'exécute en parallèle, plus la génération de blocs est rapide (plus les transactions du bloc correspondant sont exécutées rapidement), plus la preuve correspondante peut être générée à l'avance, ceci permet de réduire considérablement le temps de vérification on-chain.
Lorsque la génération de preuves est très lente, par exemple plusieurs heures, l'amélioration de l'efficacité grâce à l'utilisation de l’architecture d'exécution parallèle n'est pas évidente. Il existe deux scénarios qui peuvent améliorer l'effet du parallélisme. Le premier est que le nombre de blocs agrégés devient plus grand, de sorte que le changement quantitatif entraîne un changement qualitatif. Le second est que le temps de génération des preuves est considérablement réduit. En combinant ces deux scénarios, l'efficacité peut être considérablement augmentée.
Dans le contexte des ZKVM, atteindre la compatibilité signifie faciliter la connexion aux efforts de développement déjà réalisés sur certaines blockchains publiques. Après tout, de nombreuses applications ont déjà été développées au sein des écosystèmes existants que nous avons aujourd'hui, tel que, l'écosystème Ethereum. Par conséquent, si nous pouvons utiliser ces ressources abondantes déjà présentes en atteignant la compatibilité avec ces écosystèmes déjà développés. Ceci permettrait aux projets de migrer sans heurts, et augmentera considérablement la vitesse d'adoption des ZKVM ainsi que de la mise à l'échelle de ces écosystèmes.
L'objectif principal d'OlaVM est actuellement de construire le ZKVM le plus efficace avec le débit de transactions le plus élevé. Si notre développement initial est concluant, nos objectifs suivants consisteront à envisager d'atteindre la compatibilité avec différents écosystèmes de chaînes de blocs, en dehors de l'écosystème Ethereum qui est déjà inclus dans notre feuille de route, en prenant en charge Solidity au niveau du compilateur.
Dans l'ensemble, avec l'intégration de tous les modules susmentionnés, le diagramme de flux de données de l'ensemble du système est présenté dans la figure ci-dessous.
