Blockchain (nom) : Une machine de coordination qui permet aux participants du monde entier de collaborer le long d'un ensemble de règles communément convenues sans qu'aucun tiers ne le facilite.

Les ordinateurs sont conçus pour effectuer trois tâches : stocker des données, calculer et communiquer entre eux et avec les humains. Les blockchains ajoutent une quatrième dimension : des garanties supplémentaires que ces trois éléments (stockage, calcul et communication) se déroulent de manière convenue. Ces garanties permettent la coopération entre des étrangers sans tierce partie de confiance pour faciliter cela (décentralisé).

Ces garanties supplémentaires peuvent être économiques (théorie des jeux de confiance et incitations/dissuasions) ou cryptographiques (mathématiques de confiance), mais la plupart des applications utilisent une combinaison des deux - cryptéconomique. Cela contraste fortement avec l'état actuel majoritairement basé sur la réputation des systèmes.

Alors que Web3 est souvent décrit comme "lire, écrire, posséder", nous pensons qu'une meilleure notion pour la troisième itération d'Internet est "lire, écrire, vérifier", étant donné que l'avantage clé des blockchains publiques est calcul garantiet une vérification facile que ces garanties ont été honorées. La propriété peut être un sous-ensemble du calcul garanti si nous construisons des artefacts numériques qui peuvent être achetés, vendus et contrôlés. Cependant, de nombreux cas d'utilisation des blockchains bénéficient d'un calcul garanti mais n'impliquent pas directement la propriété. Par exemple, si votre santé dans un jeu entièrement on-chain est de 77/100 - possédez-vous cette santé ou est-elle simplement contraignante on-chain selon des règles communément convenues ? Nous soutiendrions que c'est ce dernier, mais Chris Dixonpourrait être en désaccord.

Web3 = Lire, Écrire, Vérifier

ZK et Modularité - Deux tendances qui vont accélérer

Les blockchains offrent beaucoup de raisons d'être enthousiastes, mais le modèle décentralisé ajoute également des coûts et de l'inefficacité grâce à des fonctions supplémentaires telles que la messagerie P2P et le consensus. De plus, la plupart des blockchains valident encore les transitions d'état correctes par réexécution, ce qui signifie que chaque nœud du réseau doit réexécuter les transactions pour vérifier la correction de la transition d'état proposée. Cela est gaspilleur et contraste fortement avec le modèle centralisé où une seule entité exécute. Alors qu'un système décentralisé contient toujours un certain surcoût et une réplication, l'objectif devrait être de se rapprocher asymptotiquement d'une référence centralisée en termes d'efficacité.

Même si l'infrastructure sous-jacente s'est considérablement améliorée au cours de la dernière décennie, il reste beaucoup de travail avant que les blockchains puissent gérer l'échelle de l'Internet. Nous voyons des compromis le long de deux axes principaux - expressivité et complexité - et croyons que la modularité permet une expérimentation plus rapide le long de la frontière des compromis tandis que ZK l'élargit :

• Expressivité - Quelles garanties pouvez-vous créer? Comprend la scalabilité (coût, latence, débit, etc), la confidentialité (ou la gestion des flux d'informations), la programmabilité et la composabilité.
• Dureté - À quel point ces garanties sont-elles solides? Contient la sécurité, la décentralisation et la sûrté des utilisateurs et du code.

La modularité est le degré selon lequel les composants d'un système peuvent être séparés et recombinés. Grâce à des boucles de rétroaction plus rapides et à des barrières à l'entrée plus faibles avec moins de capital requis (à la fois économique et humain) - la modularité permet une expérimentation et une spécialisation plus rapides. La question de la modularité par rapport à l'intégration n'est pas binaire, mais plutôt un spectre à expérimenter pour déterminer quelles parties il est logique de découpler et lesquelles ne le sont pas.

Les preuves de connaissance nulle, ou ZKP, permettent à une partie (le prouveur) de prouver à une autre partie (le vérificateur) qu'elle sait quelque chose de vrai, sans révéler aucune information supplémentaire au-delà de sa validité. Cela peut augmenter la scalabilité et l'efficacité en évitant la ré-exécution (passant d'un modèle où tous exécutent à vérifier, à un modèle où un seul exécute et tous vérifient), ainsi que l'expressivité en permettant la confidentialité (avec des limitations). Les ZKPs améliorent également la robustesse des garanties en remplaçant des garanties cryptonomiques plus faibles par des garanties plus fortes, ce qui est représenté en repoussant la frontière de compromis vers l'extérieur (en référence au graphique ci-dessus).

Nous croyons que la modularité et la "ZKfication de tout" sont des tendances qui continueront à s'accélérer. Alors que chacun fournit des perspectives intéressantes pour explorer l'espace individuellement, nous sommes particulièrement intéressés par le croisement des deux. Les deux questions clés qui nous intéressent sont :

1. Quelles parties de la pile modulaire ont déjà incorporé des ZKPs et lesquelles restent à explorer ?
2. Quels problèmes pourraient être atténués avec les ZKPs ?

Cependant, avant de pouvoir aborder ces questions, nous avons besoin d'une vision actualisée de ce à quoi ressemble la pile modulaire en 2024.

Empilement modulaire en 2024

L'image souvent utilisée de la pile modulaire avec quatre composants (exécution, publication de données, consensus, règlement) est utile en tant que modèle mental simple, mais nous ne pensons plus que c'est une représentation adéquate étant donné à quel point l'espace modulaire a évolué. Un découplage plus poussé conduit à de nouveaux composants qui étaient auparavant considérés comme faisant partie d'un ensemble plus important, tout en créant de nouvelles dépendances et un besoin d'interopérabilité sécurisée entre les différents composants (nous en parlerons plus tard). Étant donné la vitesse à laquelle l'espace évolue, il peut être difficile de rester à jour sur toutes les innovations à différents niveaux de la pile.

Les premières tentatives d'exploration de la pile web3 incluent celles de Kyle Samani(Multicoin) - initialement publié dans2018 et mis à jour dans 2019. Il couvre tout, de l'accès à Internet de dernière mile décentralisé (comme Hélium) à la gestion des clés par l'utilisateur final. Alors que les principes qui la sous-tendent pourraient être recyclés, certains éléments, comme la preuve et la vérification, font totalement défaut.

Avec cela à l'esprit, nous avons essayé de créer une représentation mise à jour de ce à quoi ressemble la pile modulaire en 2024, en élargissant la pile modulaire existante en quatre parties. Il est divisé par composant plutôt que par fonctionnalité, ce qui signifie que le réseau P2P, par exemple, est inclus dans le consensus plutôt que d'être séparé en tant que composant distinct - principalement parce qu'il est difficile de construire un protocole autour de cela.

ZK Dans Le Stack Modulaire

Maintenant que nous avons une vue mise à jour de la pile modulaire, nous pouvons commencer à examiner la vraie question, c'est-à-dire quelles parties de la pile ZK ont déjà été pénétrées et quels problèmes ouverts pourraient être résolus en introduisant ZK (en évitant la réexécution ou en ajoutant des fonctionnalités de confidentialité). Voici un résumé de nos conclusions, avant d'approfondir chaque composant séparément.

1 - Abstraction des opérations utilisateur

Les utilisateurs actuels des blockchains doivent naviguer à travers plusieurs chaînes, portefeuilles et interfaces, ce qui est fastidieux et constitue un frein à une adoption plus large. L'abstraction des opérations utilisateur est un terme générique désignant toute tentative de dissocier cette complexité et de permettre aux utilisateurs d'interagir avec une seule interface (par exemple, une application ou un portefeuille spécifique), toute la complexité se produisant en arrière-plan. Quelques exemples d'abstractions au niveau de l'infrastructure incluent :

• L'abstraction de compte (AA) permet aux contrats intelligents d'effectuer des transactions sans exiger de signatures d'utilisateur pour chaque opération (compte crypto programmableIl peut être utilisé pour définir qui peut signer (gestion des clés), quoi signer (charge utile tx), comment signer (algorithme de signature) et quand signer (condition d'approbation de la transaction). Ensemble, ces fonctionnalités permettent des choses comme l'utilisation de la connexion sociale pour interagir avec les dApps, l'authentification à deux facteurs, la récupération de compte et l'automatisation (signature automatique de tx). Alors que la discussion tourne souvent autour d'Ethereum (ERC-4337passé au printemps 2023), de nombreuses autres chaînes ont déjà une abstraction de compte intégrée native (Aptos, Sui, Près, ICP, Starknet, et zkSync).
• L'abstraction de chaîne permet aux utilisateurs de signer des transactions sur différentes chaînes tout en n'interagissant qu'avec un seul compte (une interface, plusieurs chaînes). Plusieurs équipes travaillent sur ce projet, y compris Proche, ICP, et Portefeuille. Ces solutions exploitent MPC et des signatures de chaînes, où la clé privée de l'autre réseau est divisée en plusieurs petites parties et partagée entre les validateurs sur la chaîne source qui signent les transactions inter-chaînes. Lorsque les utilisateurs veulent interagir avec une autre chaîne, un nombre suffisant de validateurs doit signer la transaction pour satisfaire le seuil de chiffrement. Cela garantit la sécurité, car la clé privée n'est jamais entièrement partagée n'importe où. Cependant, cela fait face au risque de collusion des validateurs, c'est pourquoi la sécurité cryptographique et la décentralisation des validateurs de la chaîne sous-jacente restent très pertinentes.
• Les intentions, à un niveau élevé, permettent de relier les souhaits et besoins des utilisateurs aux opérations pouvant être exécutées par une blockchain. Cela nécessite des solveurs d'intention - des agents spécialisés hors chaîne chargés de trouver la meilleure solution possible à l'intention de l'utilisateur. Il existe déjà plusieurs applications qui utilisent des intentions spécialisées, telles que les agrégateurs DEX ("meilleur prix") et les agrégateurs de ponts ("ponts les moins chers/les plus rapides"). Réseaux généraux de règlement des intentionsAnoma, Essentiel, Élégant) visent à faciliter l'expression d'intentions plus complexes pour les utilisateurs et la construction d'applications centrées sur l'intention pour les développeurs. Il reste cependant de nombreuses questions ouvertes, notamment la formalisation du processus, l'aspect d'un langage centré sur l'intention, l'existence systématique d'une solution optimale et sa possibilité de trouver.

Intégrations ZK existantes

• Authentification utilisant AA x ZK : Un exemple en est Sui’s zkLogin, qui permet aux utilisateurs de se connecter en utilisant des identifiants familiers tels qu'une adresse e-mail. Il utilise des ZKPs pour empêcher les tiers de relier une adresse Sui à son identifiant OAuth correspondant.
• Une vérification de signature plus efficace pour les portefeuilles AA : Vérifier les transactions dans les contrats AA peut être significativement plus coûteux que celles initiées par un compte traditionnel (EOA).Orbiteuressaie de relever ce défi avec un service de regroupement qui exploite les ZKPs pour vérifier la justesse des signatures de transaction et maintient la valeur de hachage et le solde de gaz du compte AA (à travers un arbre d'état mondial de Merkle). Grâce à l'agrégation de preuves et au partage du coût de vérification on-chain également parmi tous les utilisateurs, cela peut entraîner des économies de coûts significatives.

Problèmes ouverts que les ZKP pourraient résoudre

• Preuve de la meilleure exécution ou de l'accomplissement de l'intention : Alors que les intentions et AA peuvent simplifier la complexité pour les utilisateurs, ils peuvent également agir comme une force centralisatrice et nous obliger à nous appuyer sur des acteurs spécialisés (solveurs) pour trouver les chemins d'exécution optimaux. Plutôt que de simplement faire confiance à la bonne volonté du solveur, les preuves à divulgation nulle de connaissance pourraient potentiellement être utilisées pour prouver que le chemin optimal pour l'utilisateur a été choisi parmi ceux échantillonnés par le solveur.
• Confidentialité pour le règlement des intentions: Des protocoles comme Taïgavise à permettre un règlement d'intention entièrement protégé pour préserver la confidentialité des utilisateurs - dans le cadre d'un mouvement plus large visant à ajouter de la confidentialité (ou du moins de la confidentialité) aux réseaux blockchain. Il utilise des preuves à divulgation nulle de connaissance (Halo2) pour cacher des informations sensibles sur les transitions d'état (types d'application, parties impliquées, etc).
• Récupération de mot de passe pour les portefeuilles AA: L'idée derrière cette propositionpermet aux utilisateurs de récupérer leurs portefeuilles s'ils perdent leurs clés privées. En stockant un hash (mot de passe, nonce) sur le portefeuille du contrat, les utilisateurs peuvent générer un ZKP avec l'aide de leur mot de passe pour vérifier que c'est leur compte et demander un changement de clé privée. Une période de confirmation (3 jours ou plus) sert de protection contre les tentatives d'accès non autorisées.

2 - Séquençage

Les transactions doivent être ordonnées avant d'être ajoutées à un bloc, ce qui peut être fait de nombreuses manières : en les classant par rentabilité pour le proposant (les transactions les plus rémunératrices d'abord), dans l'ordre de leur soumission (premier arrivé, premier servi), en donnant la priorité aux transactions provenant des pools de mémoire privée, etc.

Une autre question est de savoir qui peut ordonner les transactions. Dans un monde modulaire, plusieurs parties différentes peuvent le faire, notamment le séquenceur rollup (centralisé ou décentralisé), le séquençage L1 (basé sur les rollups) et un réseau de séquençage partagé (réseau décentralisé de séquenceurs utilisé par plusieurs rollups). Tous ces éléments ontdifférentes hypothèses de confiance et capacités à l'échelle. En pratique, l'ordonnancement réel des transactions et leur regroupement en un bloc peuvent également être effectués en dehors du protocole par des acteurs spécialisés (blockbuilders).

Intégrations ZK existantes

• Vérification du cryptage correct du mempool: Rayonest un réseau de séquençage partagé qui possède un mempool crypté avec un cryptage de retard vérifiable pratique (PVDE). Les utilisateurs génèrent un ZKP qui est utilisé pour prouver que résoudre les casse-tête de verrouillage temporel conduira au déchiffrement correct des transactions valides, c'est-à-dire que la transaction inclut une signature et un nonce valides et que l'expéditeur a un solde suffisant pour payer les frais de transaction.

Problèmes ouverts que les ZKP pourraient résoudre

• Règles de séquençage vérifiables (VSR) : Soumettre le proposant/séquenceur à un ensemble de règles concernant l'ordre d'exécutionavec des garanties supplémentaires que ces règles sont suivies. La vérification peut se faire soit par des ZKPs ou des preuves de fraude, dont ces dernières exigent une caution économique suffisamment importante qui est réduite en cas de comportement frauduleux du proposant/séquenceur.

3 - Exécution (mise à l’échelle des écritures)

La couche d'exécution contient la logique de la mise à jour de l'état et c'est là que les contrats intelligents sont exécutés. En plus de renvoyer une sortie du calcul, les zkVM permettent également de prouver que les transitions d'état ont été effectuées correctement. Cela permet à d'autres participants du réseau de vérifier l'exécution correcte en ne vérifiant que la preuve, plutôt que de devoir réexécuter les transactions.

Outre une vérification plus rapide et plus efficace, un autre avantage de l'exécution prouvable est de permettre des calculs plus complexes, car vous ne rencontrez pas les problèmes typiques de gaz et de ressources limitées sur la chaîne avec le calcul hors chaîne. Cela ouvre la voie à de toutes nouvelles applications qui sont plus intensives en termes de calcul à exécuter sur des blockchains et qui tirent parti de calculs garantis.

Intégrations ZK existantes

• rouleaux zkEVM : Un type spécial de zkVM optimisé pour être compatible avec Ethereum et prouver l'environnement d'exécution EVM. Plus la compatibilité avec Ethereum est grande, plus le compromis en termes de performances est important. Plusieurs zkEVMs ont été lancés en 2023, notamment Polygon zkEVM, Ère zkSync, Faire défiler, et Linea. Polygon a récemment annoncé leur type 1 zkEVM prover, qui permet de prouver les blocs mainnet Ethereum pour 0,20 à 0,50 $ par bloc (avec des optimisations à venir pour réduire encore les coûts). RiscZero a également une solutionqui permet de prouver les blocs Ethereum mais à un coût plus élevé avec le benchmarking limité disponible.
• zkVMs alternatifs : Certains protocoles empruntent une voie alternative et optimisent les performances/la vérifiabilité (Starknet, Zorp (en anglais seulement)) ou convivialité pour les développeurs, plutôt que d'essayer d'être maximale compatible avec Ethereum. Des exemples de ce dernier incluent les protocoles zkWASM (Fluent, Delphinus Labs) et zkMOVE (M2etzkmove).
• zkVM axé sur la confidentialité : Dans ce cas, les preuves à divulgation nulle de connaissance (ZKPs) sont utilisées à deux fins : éviter la réexécution et garantir la confidentialité. Bien que la confidentialité pouvant être obtenue avec les ZKPs seules soit limitée (seuls les états privés personnels), les protocoles à venir ajoutent beaucoup d'expressivité et de programmabilité aux solutions existantes. Des exemples incluent ceux d'Aleo’s snarkVM, Aztec’sAVM, et Polygon’sMidenVM.
• ZK-coprocessors: Permet le calcul hors chaîne sur les données en chaîne (mais sans état). Les preuves à divulgation nulle sont utilisées pour prouver l'exécution correcte, ce qui permet un règlement plus rapide que les co-processeurs optimistes, mais il y a un compromis en termes de coût. Étant donné le coût et/ou la difficulté de générer des preuves à divulgation nulle, nous voyons apparaître certaines versions hybrides, telles que Brevis coChaîne, qui permet aux développeurs de choisir entre le mode ZK ou optimiste (compromis entre le coût et la difficulté des garanties).

Problèmes ouverts que les ZKP pourraient résoudre

• Enshrined zkVM: La plupart des couches de base (L1s) utilisent encore la ré-exécution pour vérifier les transitions d'état correctes. Enshrine un zkVM dans la couche de base éviterait cela, car les validateurs pourraient vérifier la preuve à la place. Cela améliorerait l'efficacité opérationnelle. La plupart des regards sont tournés vers Ethereum avec un zkEVM enshrined, mais de nombreux autres écosystèmes reposent également sur la ré-exécution.
• zkSVM: Alors que le SVM est principalement utilisé au sein de Solana L1 aujourd'hui, des équipes comme Eclipse cherchent à tirer parti du SVM pour des rollups qui se règlent sur Ethereum. Eclipse envisage également d'utiliser Risc Zéro pour les preuves de fraude ZKpour les défis potentiels des transitions d'état dans le SVM. Cependant, un zkSVM complet n'a pas encore été exploré - probablement en raison de la complexité du problème et du fait que le SVM est optimisé pour d'autres choses que la vérifiabilité.

4 - Requête de données (Lecture à l'échelle)

La requête de données, ou la lecture de données à partir de la blockchain, est une partie essentielle de la plupart des applications. Alors que beaucoup de discussions et d'efforts au cours des dernières années ont été axés sur l'augmentation des écritures (exécution) - l'augmentation des lectures est encore plus importante en raison du déséquilibre entre les deux (particulièrement dans un environnement décentralisé). Le ratio entre lecture/écriture diffère entre les blockchains, mais un point de données est Estimation de Sigque >96% de tous les appels aux nœuds sur Solana étaient des appels en lecture (selon 2 ans de données empiriques) - un ratio de lecture/écriture de 24:1.

L'extension des lectures comprend à la fois l'obtention de meilleures performances (plus de lectures par seconde) avec des clients validateurs dédiés (comme Sig sur Solana) et la possibilité d'effectuer des requêtes plus complexes (combinaison de lectures avec calcul), par exemple avec l'aide de coprocesseurs.

Un autre angle consiste à décentraliser les méthodes de requête de données. Aujourd'hui, la plupart des demandes de requête de données dans les blockchains sont facilitées par des tiers de confiance (basés sur la réputation), tels que les nœuds RPC (Infura) et indexeurs (Dune). Les exemples d'options plus décentralisées incluent Le Graphiqueet les opérateurs de preuve de stockage (qui sont également vérifiables). Il existe également plusieurs tentatives de créer un réseau RPC décentralisé, telles que Infura DINouRéseau Lava(en plus du RPC décentralisé, Lava vise à offrir ultérieurement des services d'accès aux données supplémentaires).

Intégrations ZK existantes

• Preuves de stockage: Permet de consulter à la fois des données historiques et actuelles des blockchains sans utiliser de tiers de confiance. Les zk-SNARKs sont utilisés pour la compression et pour prouver que les données correctes ont été récupérées. Des exemples de projets se développant dans cet espace incluent Axiome, Brevis, Hérodote, et Lagrange.

Problèmes ouverts que les preuves à divulgation nulle de connaissance pourraient résoudre

• Interrogation efficace de l'état privé: les projets de confidentialité utilisent souvent une variante du modèle UTXO, qui permet de meilleures fonctionnalités de confidentialité que le modèle de compte mais au détriment de la convivialité pour les développeurs. Le modèle UTXO privé peut également entraîner des problèmes de synchronisation - quelque chose Zcash a eu du mal avecdepuis 2022 après avoir connu une augmentation significative du volume des transactions protégées. Les portefeuilles doivent se synchroniser à la chaîne avant de pouvoir dépenser des fonds, ce qui constitue un défi fondamental pour le fonctionnement du réseau. En prévision de ce problème,Aztec a récemment publié une demande de propositionspour des idées concernant la découverte de notes mais aucune solution claire n'a encore été trouvée.

5 - Préparation

Avec de plus en plus d'applications intégrant des ZKPs, la preuve et la vérification deviennent rapidement une partie essentielle de la pile modulaire. Aujourd'hui, cependant, la plupart des infrastructures de preuve sont encore autorisées et centralisées, de nombreuses applications s'appuyant sur un seul prouveur.

Alors que la solution centralisée est moins complexe, décentraliser l'architecture de preuve et la diviser en un composant séparé dans la pile modulaire présente plusieurs avantages. Un des principaux avantages réside dans les garanties de vivacité, cruciales pour les applications dépendantes d'une génération de preuve fréquente. Les utilisateurs bénéficient également d'une plus grande résistance à la censure et de frais réduits grâce à la concurrence et au partage de la charge de travail entre plusieurs vérificateurs.

Nous croyons que les réseaux de prouveurs polyvalents (nombreuses applications, nombreux prouveurs) sont supérieurs aux réseaux de prouveurs pour une seule application (une application, nombreux prouveurs) en raison d'une meilleure utilisation du matériel existant et d'une complexité moindre pour les prouveurs. Une utilisation plus élevée profite également aux utilisateurs en termes de frais moins élevés, car les prouveurs n'ont pas besoin d'être compensés pour la redondance par le biais de frais plus élevés (ils doivent tout de même couvrir les coûts fixes).

Figment Capitala fourni un bon aperçu de l'état actuel de la chaîne d'approvisionnement en preuves, qui se compose à la fois de la génération de preuves et de l'agrégation de preuves (qui est en soi une génération de preuves, mais en prenant simplement deux preuves en entrée plutôt que la trace d'exécution).

Source: Figment Capital

Intégrations ZK existantes

• STARK avec enveloppe SNARK : les prouveurs STARK sont rapides et ne nécessitent pas de configuration de confiance, mais l'inconvénient est qu'ils produisent de grandes preuves qui sont prohibitivement coûteuses à vérifier sur Ethereum L1. Envelopper le STARK dans un SNARK en tant que dernière étape rend sa vérification nettement moins chère sur Ethereum. En revanche, cela ajoute de la complexité, et la sécurité de ces "systèmes de preuve composés" n'a pas été étudiée en profondeur. Des exemples de mises en œuvre existantes incluent Polygon zkEVM, Boojum dans l'ère zkSync, et RISC Zéro.
• Réseaux de preuve décentralisés à usage général : l’intégration d’un plus grand nombre d’applications dans un réseau de preuve décentralisé le rend plus efficace pour les prouveurs (utilisation plus élevée du matériel) et moins cher pour les utilisateurs (ils n’ont pas besoin de payer pour la redondance matérielle). Parmi les projets dans ce domaine, on peut citer GevulotetConcis.

Problèmes ouverts que les preuves à divulgation nulle de connaissance pourraient résoudre

• Preuves de fraude ZK : Dans les solutions optimistes, n'importe qui peut contester la transition d'état et créer une preuve de fraude pendant la période de contestation. Cependant, vérifier la preuve de fraude reste assez fastidieux car elle se fait par réexécution. Les preuves de fraude ZK visent à résoudre ce problème en créant une preuve de la transition d'état contestée, ce qui permet une vérification plus efficace (pas besoin de réexécution) et potentiellement un règlement plus rapide. Cela est en cours de travail par au moinsOptimisme(en collaboration avec O1 Labs et RiscZero), et AltLayer x RiscZero.
• Une agrégation de preuves plus efficace : Une excellente fonctionnalité des preuves à divulgation nulle de connaissance (ZKPs) est que vous pouvez agréger plusieurs preuves en une seule preuve, sans augmenter significativement les coûts de vérification. Cela permet d'amortir le coût de vérification sur plusieurs preuves ou applications. L'agrégation de preuves est également une forme de preuve, mais l'entrée est constituée de deux preuves au lieu d'une trace d'exécution. Des exemples de projets dans cet espace incluent NEBRAetGevulot.

Source: Figment Capital

6 - Publication des données (Disponibilité)

La publication des données (DP) garantit que les données sont disponibles et facilement récupérables pendant une courte période (1-2 semaines). Cela est crucial à la fois pour la sécurité (les rollups optimistes nécessitent des données d'entrée pour vérifier l'exécution correcte en les réexécutant pendant la période de contestation, 1-2 semaines) et pour la vivacité (même si un système utilise des preuves de validité, les données de transaction sous-jacentes peuvent être nécessaires pour prouver la propriété d'actifs pour les portes de sortie, les transactions forcées ou pour vérifier que les entrées correspondent aux sorties). Les utilisateurs (tels que les passerelles zk et les rollups) font face à un paiement ponctuel, qui couvre le coût de stockage des transactions et de l'état pendant une courte période jusqu'à ce qu'il soit élagué. Les réseaux de publication de données ne sont pas conçus pour le stockage à long terme des données (au lieu de cela, consultez la prochaine section pour des solutions possibles).

Celestiaa été la première couche DP alternative à lancer son mainnet (31 octobre), mais il y aura bientôt de nombreuses alternatives parmi lesquelles choisir comme Avail, EigenDA, et Près de DAsont tous censés être lancés en 2024. De plus, Ethereum’s EIP 4844 mettre à niveau la publication de données à grande échelle sur Ethereum (en plus de créer un marché de frais distinct pour le stockage d’objets blob) et préparer le terrain pour un dank-sharding complet. DP s’étend également à d’autres écosystèmes, par exemple @nubit_org/riema-sécurise-un-investissement-ange-pour-le-lancement-de-la-première-couche-de-disponibilité-de-données-native-de-bitcoin-49ccf0487380">Nubit qui vise à construire DP natif sur Bitcoin.

De nombreuses solutions DP offrent également des services au-delà de la simple publication de données, y compris la sécurité partagée pour les rollups souverains (comme CelestiaetDisponible) ou une meilleure interopérabilité entre les rollups (comme ceux d'AvailNexus). Il y a aussi des projets (DomiconetZéro gravité) qui offrent à la fois la publication de données et le stockage à long terme, ce qui est une proposition convaincante. Il s'agit également d'un exemple de recomposition de deux composants dans la pile modulaire, quelque chose que nous verrons probablement davantage à l'avenir (expérimentation à la fois avec un découplage supplémentaire et une recomposition).

Intégrations ZK existantes

• Démontrer la correction du codage d'effacement : Le codage d'effacement apporte un certain niveau de redondance de sorte que les données d'origine sont récupérables même si une partie des données encodées n'est pas disponible. C'est également une condition préalable pour le DAS où les nœuds légers échantillonnent seulement une petite partie du bloc pour assurer de manière probabiliste que les données sont là. Si un proposant malveillant encode les données de manière incorrecte, les données d'origine pourraient ne pas être récupérables même si les nœuds légers échantillonnent suffisamment de fragments uniques. Prouver la correction du codage d'effacement peut être fait soit en utilisant des preuves de validité (ZKPs) soit des preuves de fraude - ces dernières souffrant d'une latence liée à la période de défi. Toutes les autres solutions sauf Celestia travaillent sur l'utilisation de preuves de validité.
• Les clients légers ZK alimentent les ponts de données : les Rollups qui utilisent des couches de publication de données externes doivent toujours communiquer à la couche de règlement que les données ont été publiées correctement. C'est à cela que servent les ponts d'attestation de données. L'utilisation des preuves à divulgation nulle rend la vérification des signatures de consensus de la chaîne source plus efficace sur Ethereum. Both Avail’sVectorX) et Celestia’s ( BlobstreamX) les ponts d'attestation de données sont alimentés par des clients légers ZK construits avec Succinct.

Problèmes ouverts que les preuves de connaissance nulle pourraient résoudre

• Celestia incorporant des preuves de validité pour le codage d'effacement correct : Celestia est actuellement un cas particulier parmi les réseaux de publication de données car il utilise des preuves de fraude pour le codage d'effacement correct. Si un proposant de blocage malveillant encode les données de manière incorrecte, n’importe quel autre nœud complet peut générer une preuve de fraude et la contester. Bien que cette approche soit un peu plus simple à mettre en œuvre, elle introduit également une latence (le blocage n’est définitif qu’après la fenêtre de preuve de la fraude) et oblige les nœuds légers à faire confiance à un nœud complet honnête pour générer la preuve de la fraude (ils ne peuvent pas la vérifier eux-mêmes). Toutefois Celestia exploreen combinant leur codage Reed-Solomon actuel avec un ZKP pour prouver le codage correct, ce qui réduirait considérablement la finalité. La dernière discussion sur ce sujet peut être trouvée iciavec des enregistrements des groupes de travail précédents (en plus de tentatives plus générales d'ajouter des preuves à divulgation nulle de connaissance à la couche de base de Celestia).
• ZK-proving DAS: Il y a eu quelques explorations surDonnées de disponibilité de la preuve ZK, où les nœuds légers se contenteraient de vérifier la racine de Merkle et d'une preuve de connaissance nulle, plutôt que de devoir effectuer l'échantillonnage habituel en téléchargeant de petits morceaux de données. Cela réduirait encore davantage les exigences pour les nœuds légers, mais il semble que le développement soit au point mort.

7 - Stockage à long terme (État)

Stocker des données historiques est important principalement à des fins de synchronisation et de traitement des demandes de données. Cependant, il n'est pas réalisable pour chaque nœud complet de stocker toutes les données et la plupart des nœuds complets élaguent les anciennes données pour maintenir des exigences matérielles raisonnables. À la place, nous nous appuyons sur des parties spécialisées (nœuds d'archive et indexeurs) pour stocker toutes les données historiques et les rendre disponibles à la demande des utilisateurs.

Il existe également des fournisseurs de stockage décentralisé, tels que FilecoinouArweave, qui offrent des solutions de stockage décentralisé à long terme à un prix raisonnable. Alors que la plupart des blockchains n'ont pas de processus formel de stockage d'archives (simplement se fier à quelqu'un pour le stocker), les protocoles de stockage décentralisé sont de bons candidats pour stocker l'historique et ajouter une certaine redondance (au moins X nœuds stockent les données) grâce aux incitations intégrées au réseau de stockage.

Intégrations ZK existantes

• Preuve de stockage : Les fournisseurs de stockage à long terme doivent générer régulièrement des preuves de connaissance nulle pour prouver qu'ils ont stocké toutes les données qu'ils revendiquent. Un exemple de ceci est Preuve de l'espace-temps de Filecoin(PoSt), où les fournisseurs de stockage gagnent des récompenses de bloc à chaque fois qu'ils répondent avec succès à un défi PoSt.

Problèmes ouverts que les ZKP pourraient résoudre

• Prouver la provenance des données et l'autorisation de visualiser des données sensibles : Avec deux parties non fiables qui souhaitent échanger des données sensibles, les preuves à divulgation nulle pourraient être utilisées pour prouver qu'une partie possède les attestations requises pour visualiser les données sans avoir à télécharger des documents réels ou divulguer des mots de passe et des détails de connexion.

8 - Consensus

Étant donné que les blockchains sont des systèmes distribués de pair à pair, il n'y a pas de tiers de confiance qui détermine la vérité globale. Au lieu de cela, les nœuds du réseau s'accordent sur ce qui constitue la vérité actuelle (quel bloc est le bon) grâce à un mécanisme appelé consensus. Les méthodes de consensus basées sur la preuve d'enjeu (PoS) pourraient être catégorisées soit comme étant basées sur le BFT (où le quorum de validateurs tolérant les fautes byzantines décide de l'état final) soit comme étant basées sur la chaîne (où l'état final est décidé rétrospectivement par la règle de choix de fourche). Alors que la plupart des implémentations de consensus PoS existantes sont basées sur le BFT, Cardanoest un exemple d'implémentation de la chaîne la plus longue. Il y a aussi un intérêt croissant pour les mécanismes de consensus basés sur le DAG tels que Narwhal-Bullshark qui est mis en œuvre dans certaines variations à travers Aleo, Aptos et Sui.

Le consensus est une partie cruciale de nombreux composants différents de la pile modulaire, y compris le séquenceur partagé, la preuve décentralisée et les réseaux de publication de données basés sur la blockchain (et non basés sur un comité comme EigenDA).

Intégrations ZK existantes

• Le jalonnement dans les réseaux de confidentialité basés sur ZK : les réseaux de confidentialité basés sur PoS posent un défi, car les détenteurs des jetons de jalonnement doivent choisir entre la confidentialité et la participation au consensus (et recevoir des récompenses de jalonnement).Penumbra vise à résoudre celaen éliminant les récompenses de mise, traitant plutôt les mises non liées et liées comme des actifs séparés. Cette méthode garde les délégations individuelles privées, tandis que le montant total lié à chaque validateur reste public.
• Gouvernance privée : Parvenir à un vote anonyme a longtemps été un défi dans la cryptographie, avec des projets tels que Vote privé sur Nounsessayer de faire avancer cela. Il en va de même pour la gouvernance, où le vote anonyme sur les propositions est en cours de développement par au moins Penumbra. Dans ce cas, les preuves à divulgation nulle de connaissance (ZKP) peuvent être utilisées pour prouver que l'on a le droit de voter (par exemple par le biais de la possession de jetons) et que certains critères de vote sont remplis (n'a pas déjà voté, par exemple).

Problèmes ouverts que les preuves de connaissance nulle pourraient résoudre

• Élection de chef privé: Ethereum élit actuellement les 32 prochains proposants de blocs au début de chaque époque et les résultats de cette élection sont publics. Cela impose le risque qu'une partie malveillante lance une attaque par déni de service (DoS) contre chaque proposant séquentiellement pour tenter de désactiver Ethereum. Dans une tentative de résoudre ce problème, FouetIl s'agit d'une proposition de protocole préservant la vie privée pour l'élection des proposants de blocs sur Ethereum. Les preuves à divulgation nulle de connaissance (ZKPs) sont utilisées par les validateurs pour prouver que le mélange et la randomisation ont été effectués de manière honnête. Il existe d'autres approches également pour atteindre un objectif similaire, certaines d'entre elles sont couvertes dans cebillet de blog de a16z.
• Agrégation de signatures : Utiliser des preuves de connaissance nulle pour agréger des signatures pourrait réduire considérablement la surcharge de communication et de calcul de la vérification des signatures (vérifier une preuve agrégée au lieu de chaque signature individuelle). C'est quelque chose qui est déjà exploité dans les clients légers ZK, mais qui pourrait potentiellement être étendu au consensus également.

9 - Règlement

Le règlement s’apparente à la plus haute cour de justice - la source finale de vérité où l’exactitude des transitions d’État est vérifiée et les différends sont réglés. Une transaction est considérée comme définitive au moment où elle est irréversible (ou, dans le cas d’une finalité probabiliste, au moment où il serait suffisamment difficile de l’annuler). Le délai de finalité dépend de la couche de règlement sous-jacente utilisée, qui dépend à son tour de la règle de finalité spécifique utilisée et du temps de bloc.

La lenteur de la finalité est particulièrement problématique dans la communication inter-rollup, où les rollups doivent attendre la confirmation d'Ethereum avant de pouvoir approuver une transaction (7 jours pour les rollups optimistes, 12 minutes et temps de preuve pour les rollups de validité). Cela conduit à une mauvaise expérience utilisateur. Plusieurs efforts sont déployés pour résoudre ce problème en utilisant des pré-confirmations avec un certain niveau de sécurité. Des exemples incluent à la fois des solutions spécifiques à l'écosystème (Gate.io)Couche AggLayer surfaciqueouzkSync HyperBridge) et des solutions polyvalentes telles que Couche de finalité rapide de Nearqui vise à connecter plusieurs écosystèmes rollup différents en tirant parti de la sécurité économique d'EigenLayer. Il y a aussi l'option deponts rollup natifs exploitant EigenLayerpour des confirmations rapides afin d'éviter d'attendre la pleine finalité.

Intégrations ZK existantes

• Un règlement plus rapide avec des rollups de validité : Contrairement aux rollups optimistes, les rollups de validité ne nécessitent pas de période de contestation car ils s'appuient sur des preuves à divulgation nulle pour prouver la transition d'état correcte que quelqu'un conteste ou non (rollups pessimistes). Cela rend le règlement sur la couche de base beaucoup plus rapide (12 minutes contre 7 jours sur Ethereum) et évite la ré-exécution.

10 - Sécurité

La sécurité est liée à la solidité des garanties et constitue une partie cruciale de la proposition de valeur des blockchains. Cependant, le démarrage de la sécurité cryptéconomique est difficile - augmentant les barrières à l'entrée et agissant comme un frein à l'innovation pour les applications qui en ont besoin (différents intergiciels et L1 alternatifs).

L'idée de sécurité partagée est d'utiliser la sécurité économique existante des réseaux PoS et de la soumettre à un risque de réduction supplémentaire (conditions de sanction), plutôt que chaque composant essayant de démarrer le sien. Il y a eu quelques tentatives antérieures de faire la même chose dans les réseaux PoW (minage fusionné.)), mais des incitations mal alignées ont facilité la collusion et l’exploitation d’un protocole par les mineurs (plus difficile de punir les mauvais comportements car le travail se déroule dans le monde physique, c’est-à-dire le minage en utilisant la puissance de calcul). La sécurité PoS est plus flexible pour être utilisée par d’autres protocoles, car elle présente à la fois des incitations positives (rendement du jalonnement) et négatives (réduction des coûts).

Les protocoles construits autour du principe de sécurité partagée incluent:

• EigenLayer vise à exploiter la sécurité existante d'Ethereum pour sécuriser un large éventail d'applications. Le livre blanc a été publié début 2023, et EigenLayer est actuellement en version alpha du réseau principal, avec un lancement complet du réseau principal prévu plus tard cette année.
• Cosmos a lancé son Sécurité interchaîne(ICS) en mai 2023, ce qui permet au Cosmos Hub - l'une des plus grandes chaînes sur Cosmos et soutenue par ~2,4 milliards de ATOM misés- louer sa sécurité aux chaînes de consommateurs. En utilisant le même ensemble de validateurs qui alimente le Cosmos Hub pour valider également les blocs sur la chaîne de consommateurs, elle vise à réduire la barrière au lancement de nouvelles chaînes sur le dessus de la pile Cosmos. Actuellement, cependant, seuls deux chaînes de consommation sont en direct (Neutron and Stride).
• Babylon cherche également à permettre à BTC d'être utilisé pour la sécurité partagée. Pour contrer les problèmes liés au minage fusionné (difficile de punir les mauvais comportements), il construit une couche virtuelle de preuve d'enjeu où les utilisateurs peuvent verrouiller des BTC dans un contrat de mise en jeu sur Bitcoin (pas de pontage). Comme Bitcoin n'a pas de couche de contrat intelligent, les règles de réduction des contrats de mise en jeu sont exprimées en termes de transactions UTXO écrites dans le script Bitcoin.
• Le restaking sur d'autres réseaux inclut Pieuvresur Near et Picasso sur Solana. PolkadotParachainsexploite également le concept de sécurité partagée.

Intégrations ZK existantes

• Mélange entre la sécurité ZK et économique : Bien que les garanties de sécurité basées sur ZK puissent être plus solides, prouver reste encore prohibitivement cher pour certaines applications et la génération de la preuve prend trop de temps. Un exemple en est Brevis coChain, qui est un coprocesseur qui tire sa sécurité économique des re-stakers ETH et garantit une optimisation du calcul de manière optimiste (avec des preuves de fraude ZK). Les dApps peuvent choisir entre le mode pure-ZK ou coChain, en fonction de leurs besoins spécifiques en matière de sécurité et de compromis coût.

11 - Interopérabilité

L'interopérabilité sûre et efficace reste un grand défi dans un monde multi-chaînes, illustré par le 2.8 milliards de dollars perdus dans des piratages de ponts. Dans les systèmes modulaires, l'interopérabilité devient encore plus importante - Non seulement vous communiquez entre d'autres chaînes, mais les blockchains modulaires nécessitent également que différents composants communiquent entre eux (comme la couche DA et de règlement). Il n'est donc plus possible de simplement exécuter un nœud complet ou de vérifier une seule preuve de consensus comme dans les blockchains intégrées. Cela ajoute plus d'éléments en mouvement à l'équation.

L’interopérabilité comprend à la fois le pontage de jetons et la transmission de messages plus généraux entre les blockchains. Il existe plusieurs options différentes qui font toutes des compromis différents en matière de sécurité, de latence et de coût. L’optimisation pour les trois est très difficile, ce qui nécessite généralement d’en sacrifier au moins un. De plus, les normes différentes d’une chaîne à l’autre rendent plus difficile la mise en œuvre sur de nouvelles chaînes.

Alors que nous manquons encore d'une définition claire des différents types de clients légers (ou nœuds), ce post par Dino(co-fondateur de Fluent & Modular Media) donne une bonne introduction. La plupart des clients légers vérifient aujourd'hui uniquement le consensus, mais idéalement, nous aurions des clients légers qui pourraient vérifier également l'exécution et DA pour réduire les hypothèses de confiance. Cela permettrait de se rapprocher de la sécurité des nœuds complets, sans les exigences matérielles élevées.

Intégrations ZK existantes

• ZK clients légers (vérification du consensus): La plupart des clients légers actuels permettent de vérifier le consensus de l'autre chaîne - soit l'ensemble complet des validateurs (si suffisamment petit) soit un sous-ensemble des validateurs totaux (comme Le comité de synchronisation d'Ethereum). Les ZKP sont utilisées pour rendre la vérification plus rapide et moins coûteuse, car le schéma de signature utilisé sur la chaîne d'origine pourrait ne pas être nativement pris en charge sur la chaîne de destination. Alors que l'importance des clients légers ZK dans le pontage devrait augmenter, les frictions actuelles pour une adoption plus large incluent le coût de la preuve et de la vérification ainsi que la mise en œuvre des clients légers ZK pour chaque nouvelle chaîne. Des exemples de protocoles dans cet espace incluent Polyèdres, les ponts d'attestation de données d'Avail et de Celestia, et zkIBC par Electron Labs.
• Preuves de stockage : Comme mentionné précédemment, les preuves de stockage permettent d'interroger à la fois des données historiques et actuelles des blockchains sans avoir recours à des tiers de confiance. Ceci est également pertinent pour l'interopérabilité car elles pourraient être utilisées pour la communication inter-chaînes. Par exemple, un utilisateur pourrait prouver qu'il possède des jetons sur une chaîne et utiliser cela pour la gouvernance sur une autre chaîne (sans avoir besoin de pont). Il existe également des tentatives d'utilisation de preuves de stockage pour le pontage, telles que cette solution développée par LambdaClass.
• ZK Oracles: Les oracles agissent en tant qu'intermédiaires et relient les données du monde réel à la blockchain. Les oracles ZK améliorent les modèles d'oracle actuels basés sur la réputation en permettant de prouver l'origine et l'intégrité des données, ainsi que toute computation effectuée sur ces données.

Problèmes Ouverts Que les Preuves à Divulgation Zéro Pourraient Résoudre

• Clients légers complets : Au lieu de faire confiance aveuglément à l'ensemble des validateurs de l'autre chaîne, les clients légers complets vérifient également l'exécution correcte et l'AD. Cela réduit les hypothèses de confiance et se rapproche d'un nœud complet, tout en maintenant des exigences matérielles faibles (permettant à plus de personnes d'exécuter des clients légers). Cependant, vérifier autre chose que le consensus reste prohibitif sur la plupart des chaînes, en particulier Ethereum. De plus, les clients légers ne permettent que la vérification des informations (la moitié du problème), c'est-à-dire qu'ils peuvent identifier que l'information est fausse, mais il doit encore exister un mécanisme supplémentaire pour qu'ils fassent quelque chose à ce sujet.
• Couches d'agrégation: AggLayer de Polygonvise à permettre une interopérabilité fluide entre les L2 au sein de l'écosystème en exploitant des preuves agrégées et un contrat de pont unifié. La preuve agrégée permet à la fois une vérification plus efficace et une sécurité renforcée, garantissant que les états de chaîne dépendants et les bundles sont cohérents et s'assurant qu'un état de rollup ne peut pas être réglé sur Ethereum s'il dépend d'un état invalide d'une autre chaîne.HyperChains de zkSyncetAvail Nexusadoptent une approche similaire.

Quand Gate a-t-il mangé la pile modulaire ZK?

En supposant que nous puissions atteindre un état où la génération des preuves à divulgation nulle de connaissance (ZKPs) devient très rapide (presque à la vitesse de la lumière) et incroyablement bon marché (presque gratuit), à quoi ressemble le résultat final ? En d'autres termes, quand est-ce que ZK a consommé la pile modulaire ?

De manière générale, nous croyons que deux choses seraient vraies dans cet état du monde:

1. Toute ré-exécution inutile est éliminée : En passant à un modèle d'exécution 1/N (plutôt que N/N avec ré-exécution), nous réduisons significativement la redondance globale du réseau et permettons une utilisation plus efficace du matériel sous-jacent. Bien qu'il reste un certain surcoût, cela aiderait les blockchains à se rapprocher asymptotiquement des systèmes centralisés en termes d'efficacité computationnelle.
2. La plupart des applications s'appuient sur des garanties cryptographiques activées par ZK plutôt que sur la sécurité économique : Lorsque le coût et le temps de génération des preuves ne sont plus une considération pertinente, nous croyons que la plupart des applications s'appuieront sur les preuves à divulgation nulle de connaissance pour des garanties plus solides. Cela nécessite également certaines améliorations en termes d'utilisabilité et de convivialité pour les développeurs afin de construire des applications ZK, mais ce sont tous des problèmes sur lesquels travaillent plusieurs équipes.

Une troisième condition concernerait la confidentialité (ou la gestion des flux d'informations), mais c'est plus compliqué. Les ZKPs peuvent être utilisés pour certaines applications de confidentialité avec une preuve côté client, ce sur quoi des plateformes comme Aleo, Aztec ou Polygon Miden travaillent, mais la réalisation d'une confidentialité à grande échelle pour tous les cas d'utilisation potentiels repose également sur les progrès du MPC et du FHE - un sujet potentiel pour un futur article de blog.

Risques pour notre thèse

Et si nous avions tort, et que l'avenir n'est ni modulaire ni ZK'fied? Certains risques potentiels pour notre thèse incluent:

La modularité augmente la complexité

Tant les utilisateurs que les développeurs souffrent du nombre croissant de chaînes. Les utilisateurs doivent gérer des fonds sur plusieurs chaînes (et potentiellement plusieurs portefeuilles). Les développeurs d'applications, quant à eux, ont moins de stabilité et de prévisibilité étant donné à quel point l'espace évolue encore, ce qui rend plus difficile de décider sur quelle chaîne construire. Ils doivent également penser à la fragmentation de l'état et de la liquidité. Cela est particulièrement vrai maintenant alors que nous expérimentons encore le front pionnier des composants qu'il convient de découpler et ceux qui seront recouplés. Nous croyons que l'abstraction des opérations utilisateur ainsi que des solutions d'interopérabilité sûres et efficaces sont des éléments cruciaux pour résoudre ce problème.

Est-ce que ZK sera jamais assez performant ?

Il est indéniable que la génération de preuves prend trop de temps et que le coût de la preuve et de la vérification est encore beaucoup trop élevé aujourd'hui. Des solutions concurrentes telles que les environnements d'exécution de confiance/TEEs (confidentialité) ou des solutions de sécurité optimistes/cryptéconomiques (coût) ont encore plus de sens pour de nombreuses applications aujourd'hui.

Beaucoup de travail est toutefois en cours concernant l'optimisation des logiciels et l'accélération matérielle pour les preuves à divulgation nulle de connaissance (ZKPs). L'agrégation des preuves contribuera à réduire davantage les coûts de vérification en répartissant le coût entre plusieurs parties différentes (coût inférieur/utilisateur). Il est également possible d'adapter la couche de base pour qu'elle soit plus optimisée pour la vérification des ZKPs. Un défi concernant l'accélération matérielle pour les ZKPs est le développement rapide des systèmes de preuve. Cela rend difficile la création de matériel spécialisé (ASIC) car il risque de devenir rapidement obsolète si/quand les normes des systèmes de preuve sous-jacents évoluent.

Ingonyamaa tenté de créer un certain benchmarking pour la performance du prouveur à travers une métrique comparable appelée score ZK. Il est basé sur le coût de l'exécution du calcul (OPEX) et suit MMOPS/WATT, où MMOPS signifie opérations de multiplication modulaire par seconde. Pour en savoir plus sur le sujet, nous recommandons les blogs de @Cysic/BJQcpVbXn?ref=blog.succinct.xyz">Cysic and @ingonyama/revisiting-paradigms-hardware-acceleration-for-zero-knowledge-proofs-5dffacdc24b4">Ingonyama, ainsi que cette discussion par Wei Dai.

Est-ce que la confidentialité limitée que les preuves de connaissance nulle peuvent fournir est utile ?

ZKPs ne peuvent être utilisés que pour garantir la confidentialité de l'état personnel, et non de l'état partagé où plusieurs parties doivent effectuer des calculs sur des données chiffrées (comme un Uniswap privé). FHE et MPC sont également nécessaires pour assurer une confidentialité totale, mais ils doivent améliorer leur coût et leurs performances de plusieurs ordres de magnitude avant de devenir des options viables pour une utilisation à plus grande échelle. Cela dit, les ZKPs restent utiles pour certains cas d'utilisation ne nécessitant pas un état partagé privé, tels que les solutions d'identité ou les paiements. Tous les problèmes ne nécessitent pas d'être résolus avec le même outil.

Résumé

Alors, où cela nous laisse-t-il? Alors que nous progressons chaque jour, il reste encore beaucoup de travail. Les problèmes les plus pressants à résoudre sont comment la valeur et l'information peuvent circuler en toute sécurité entre différents composants modulaires sans sacrifier la vitesse ou le coût, ainsi que l'abstraction de tout cela de l'utilisateur final afin qu'ils n'aient pas à se soucier de faire le pont entre différentes chaînes, de changer de portefeuille, etc.

Alors que nous sommes actuellement encore très largement dans la phase d'expérimentation, les choses devraient se stabiliser avec le temps alors que nous découvrons où se situent les compromis optimaux pour chaque cas d'utilisation. Cela permettra à son tour l'émergence de normes (informelles ou formelles) et apportera plus de stabilité aux constructeurs au-dessus de ces chaînes.

Aujourd'hui, il existe encore de nombreux cas d'utilisation qui recourent par défaut à la sécurité cryptonomique en raison du coût et de la complexité de la génération de ZKPs, et certains qui nécessitent une combinaison des deux. Cependant, cette part devrait diminuer avec le temps alors que nous concevons des systèmes de preuve plus efficaces et du matériel spécialisé pour réduire le coût et la latence de la preuve et de la vérification. Avec chaque réduction exponentielle des coûts et de la vitesse, de nouveaux cas d'utilisation sont débloqués.

Bien que cet article soit axé sur les ZKPs en particulier, nous sommes également de plus en plus intéressés par la façon dont les solutions de cryptographie moderne (ZKPs, MPC, FHE et TEE) finiront par jouer ensemble - quelque chose que nous voyons déjà.

Merci de lire!

Avertissement：

1. Cet article est repris de [équilibre]. Tous les droits d'auteur appartiennent à l'auteur original [ Hannes Huitula]. Si des objections sont faites à cette reproduction, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en matière d'investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.