Au début du siècle dernier, si vous vouliez une voiture, vous deviez chercher le mécanicien le plus réputé de la région. Il fabriquerait chaque engrenage et tige à la main selon vos besoins. Si la voiture tombait en panne, personne d'autre que lui ne pouvait la réparer, car chaque spécification de pièce n'existait que dans sa tête. Cela s'appelle "artisanat", et aussi "barrière technique".
Puis la chaîne de montage de Ford est arrivée. Les pièces ont été normalisées, et le processus d'assemblage est devenu transparent. Les mécaniciens ont-ils perdu leur emploi ? Non, ils sont devenus des ingénieurs en chef, et les personnes qui ne pouvaient pas se permettre une voiture auparavant, chaque foyer a maintenant une voiture de type T.
Le développement ZK (preuve à zéro connaissance) est actuellement dans cette ère "artisanale" sauvage.
Un, le coûteux "prêtre cryptographique"
Dans le cercle de la blockchain, les développeurs ZK sont ceux qui se trouvent au sommet de la pyramide. Ils sont comme une bande de "prêtres" maîtrisant d'anciens sorts, gardant des courbes elliptiques, des engagements polynomiaux et des circuits R1CS, des logiques mathématiques que le grand public n'a même jamais entendues.
Si vous êtes un développeur Web3 ordinaire et que vous souhaitez ajouter une fonction de "vote privé" ou "anonymat" à votre application, vous n'avez que deux choix :
Pousser les maths : Passer deux ou trois ans à déchiffrer ces articles cryptographiques obscurs, et avant d'écrire du code, se transformer en demi-mathématicien.
Recrutement de haut niveau : Dépenser une fortune pour engager les rares experts en ZK au monde.
Le résultat est évident. La plupart des équipes ont regardé les factures et les calendriers, et ont finalement soupiré : "Oublions cela, la vie privée ou pas, on en reparlera plus tard." C'est pourquoi la piste ZK est bien notée mais peu fréquentée - la technologie est trop sacrée, le seuil est trop décourageant.
Deux, déconstruction violente : la "frappe dimensionnelle" de Compact
@MidnightNetwork Le langage Compact que nous développons est en fait un mouvement de "dé-sacralisation".
Si le développement traditionnel de ZK consiste à "polir à la main des lentilles", alors Compact fournit une "meuleuse automatique".
La finesse de Compact réside dans le fait qu'il n'a pas inventé un nouveau langage hautain, mais a choisi de "parasiter" sur TypeScript. C'est une stratégie extrêmement rusée et pragmatique. Qu'est-ce que TypeScript ? C'est la langue maternelle des ingénieurs frontend, le boulon le plus mature de l'industrie de l'internet.
La planéité de Compact par rapport à ZK se manifeste à travers trois niveaux de "dissolution" :
Résolution logique : Les développeurs n'ont plus besoin de penser à "comment transformer la logique métier en contraintes polynomiales". Vous n'avez qu'à décrire vos règles métier avec des if-else, des boucles et des fonctions familières, le reste est laissé au compilateur.
Dissolution de l'identité : Auparavant, vous aviez besoin d'un "expert en cryptographie", maintenant vous n'avez besoin que d'un "programmeur qui comprend un peu de logique". Cela signifie que le coût organisationnel pour développer des applications privées est passé de "chercher une licorne" à "recruter des ouvriers qualifiés".
Dissolution mentale : Lorsque vous écrivez du code, vous n'avez pas à vous soucier en permanence de la solidité de la preuve mathématique sous-jacente. Le compilateur de Compact génère automatiquement pour vous la description du circuit sous-jacent et les matériaux de preuve. C'est comme écrire du code dans un langage de haut niveau sans se soucier de comment le registre du CPU fonctionne.
Trois, le "tremblement de terre" de la structure du marché
Tout comme cette vidéo qui vous apprend à changer l'écran de votre téléphone, lorsque quelque chose de "difficile" devient "facile", les changements qui se produisent ne concernent pas seulement l'efficacité.
Tout d'abord, l'effondrement du pouvoir de tarification.
Auparavant, les projets ZK pouvaient demander des financements exorbitants, en grande partie en raison de la "prime de rareté des talents". Lorsque Compact permettra à des millions de développeurs TypeScript de rédiger des contrats privés, cette prime va rapidement diminuer. Le "mystère" de la technologie disparaît, remplacé par la "compétition des cas d'utilisation".
Ensuite, il y a l'"explosion de biodiversité" de l'écosystème des applications.
Pourquoi y a-t-il si peu d'applications ZK en ce moment ? Parce que le coût est trop élevé, tout le monde n'ose jouer que dans le domaine à haute valeur ajoutée et à haut rendement (DeFi). Mais si les coûts de développement descendent à un dixième de ce qu'ils étaient, alors ces scénarios qui semblent "moins rentables mais très utiles" commenceront à émerger :
Un système d'évaluation anonyme des employés.
Un protocole de réputation sociale décentralisé basé sur la protection de la vie privée.
Une preuve de prêt qui n'exige pas de révéler le solde pour prouver la force des actifs.
Ces choses étaient impossibles à réaliser à l'ère "artisanale", car les investissements en R&D ne pouvaient tout simplement pas être récupérés. Mais après la généralisation de Compact, tout cela deviendra des "petits plugins" à portée de main.
Quatre, le "vallée de la mort" entre idéaux et réalités
Mais en y réfléchissant, après avoir changé l'écran de mon téléphone, j'ai découvert un problème : bien que l'écran ait été remplacé, le mastic n'a pas été appliqué uniformément, rendant l'étanchéité pratiquement nulle. C'est l'effet secondaire de la "planéité" - un seuil d'entrée plus bas ne signifie pas qu'il n'y a pas de pièges.
Le Compact de Midnight fait également face à ce défi. Peu importe à quel point le whitepaper est bien écrit ou à quel point le compilateur est intelligent, si l'efficacité du circuit produit est faible (taille de preuve trop grande ou temps de vérification trop long), ou s'il y a des vulnérabilités de sécurité dans des conditions extrêmes, alors les développeurs hésiteront toujours à migrer à grande échelle.
Les développeurs sont un groupe très réaliste. Ils ont une tolérance très faible pour les outils :
Documentation : Si je cherche une erreur et que je ne trouve pas de solution, je pars immédiatement.
Débogage : Si je commets une erreur dans la logique et que le compilateur me dit "Erreur inconnue", je vais sûrement fracasser mon clavier.
Compatibilité : Peut-il s'intégrer sans couture dans mon flux de développement existant ?
Midnight dit qu'ils fourniront un ensemble complet d'environnement de développement et de cadre de soutien, cela semble très bien, mais le véritable champ de bataille est dans les trois mois suivant le lancement du mainnet. À ce moment-là, la rapidité avec laquelle les bugs dans la communauté sont résolus et la fréquence des mises à jour des tutoriels décideront s'il deviendra la prochaine norme de l'industrie ou s'il se transformera en un "jouet de laboratoire qui a l'air cool mais que personne n'utilise".
Cinq, conclusion : l'avenir après la planéité
J'ai toujours pensé qu'un signe de maturité d'une technologie est qu'elle devient "invisible".
Lorsque vous achetez quelque chose sur Taobao, vous n'avez pas besoin de savoir comment la base de données distribuée fonctionne pour le partitionnement ; lorsque vous ouvrez une page web, vous n'avez pas besoin de savoir comment le protocole TCP/IP établit la connexion. Les ZK devraient également être comme ça.
L'objectif de Compact devrait être de faire disparaître le terme "preuve à zéro connaissance" des discussions des développeurs. Les gens ne discutent plus de "comment écrire un circuit ZK", mais de "quelles fonctionnalités mon contrat privé a-t-il réalisées".
Comme le dit la section de commentaires de la vidéo de changement d'écran : "Ah, c'est comme ça, je peux aussi écrire."
Si ce jour arrive vraiment, les applications privées commenceront véritablement leur récit. Quant à savoir si cela va fonctionner, nous ne regardons pas les PPT, mais les historiques de commit sur GitHub après le lancement du mainnet.
