Par Misha Komarov, Blockworks, compilé par Song Xue, Golden Finance
Le Web3 met tellement l’accent sur le concept de base de la technologie à connaissance nulle qu’il est maintenant devenu un fondement et le centre de chaque développement. Mais ses avantages en matière d’évolutivité, de sécurité et de confidentialité ne le rendent pas digne de confiance.
Ce que les gens ne réalisent pas, c’est que dans l’environnement Web3, la technologie zero-knowledge (ZK) est encore assez nouvelle et n’est pas sans défauts. Les développeurs s’attaquent activement aux problèmes actuels de la technologie ZK, mais la nature innovante de l’espace signifie qu’ils ont tendance à conceptualiser plus vite qu’ils ne peuvent construire.
Continuer à faire confiance à ZK sans bien comprendre ses problèmes techniques est dangereux pour un avenir Web3 durable. Avant de se fier aveuglément à cette technologie, nous devons l’examiner en profondeur et ses inconvénients potentiels. **
Il ne devrait pas y avoir de héros dans le Web3 – aucune technologie ne devrait être vénérée. **
Dans un avenir idéal, la technologie ZK jouera un rôle plus intégré dans toutes les activités on-chain. Cependant, la technologie existe actuellement presque comme un add-on ou un accessoire, plutôt que comme quelque chose qui est capable de prendre fondamentalement en charge l’exécution on-chain. ** Cela s’explique par le fait que les domaines et les produits en cours de développement sont encore relativement récents.
Mais le domaine de la technologie ZK s’est développé au point qu’il risque de se compliquer à l’excès. Il existe un fossé croissant entre les constructeurs ZK et les utilisateurs du Web3. **
Parmi les autres problèmes rencontrés par le développement technologique de ZK, citons l’optimisation des délais de mise sur le marché sans compromettre l’intégrité du projet. Les preuves et les circuits ZK manquent actuellement d’accessibilité car les développeurs doivent apprendre des langages spécifiques à un domaine (DSL) pour prouver davantage ces calculs.
Il s’agit d’un processus à forte intensité de connaissances, comme en témoigne le fait qu’il s’est écoulé près d’un an et demi entre le test pré-alpha de Scroll et le lancement du réseau principal. En prenant le temps de faire la bonne implémentation et la bonne revue de code, le délai de mise sur le marché de Scroll peut être entravé par un processus d’examen approfondi du code de circuit zkEVM mis en œuvre par le biais de certains zkDSL personnalisés liés à Halo2.
C’est un problème car seules quelques personnes dans le monde ont une connaissance directe de l’ADSL et de la cryptographie. Au fur et à mesure que de plus en plus de développeurs utilisent la technologie avancée ZK, nous devons nous assurer que chaque composant de la technologie ZK est vérifiable de manière indépendante.
Ensuite, il y a le défi de la configurabilité. Chaque mise à niveau nécessaire est en fin de compte une refonte complète du système nouvellement construit, et non une « mise à niveau » dans le sens où le développeur construit sur un framework existant.
Les projets qui prennent en charge ZK travaillent déjà sur des solutions qui simplifient le processus de construction pour les développeurs. Cela permettra de résoudre des problèmes clés, notamment la lenteur de la mise sur le marché, le coût de la génération de preuves en tant que partie indépendante, la configurabilité des circuits et la nécessité d’apprendre des langages cryptographiques spécifiques.
Il est essentiel de créer des moyens plus simples de compiler du code en circuits entièrement fonctionnels aussi facilement que possible pour garantir la composabilité des applications compatibles ZK. Des outils tels que les compilateurs peuvent rapidement vous aider à vérifier la fonctionnalité de votre code. Les développeurs peuvent également utiliser une variété de langages de codage pour développer des applications plus efficaces.
Continuer à se concentrer sur le travail essentiel qui a une incidence sur l’évolutivité et la sécurité sur d’autres questions en cours dans ce domaine. **Les lacunes de la technologie ZK sont ignorées simplement parce que l’industrie a désespérément besoin d’évolutivité et de sécurité, ignorant les lacunes du coût et de la complexité. **
La vérité est que la technologie ZK doit rendre les choses simples. Les développeurs devraient être en mesure d’utiliser la technologie même s’ils ne sont pas des experts en cryptographie ou en conception de circuits.
Les fournisseurs d’infrastructure ZK doivent créer des outils qui facilitent la création d’applications compatibles ZK et simplifient le processus de création pour les développeurs.
La rationalisation des procédures de production et la réduction des coûts liés à l’infrastructure sont un moyen de résoudre ces problèmes. Une autre approche possible consiste à fournir plus de ressources et de soutien, tels que des programmes éducatifs et des possibilités de mentorat, aux développeurs qui cherchent à entrer dans le domaine.
En fin de compte, même avec la technologie ZK, ne vous contentez pas de faire confiance, mais de vérifier. **
Cela va au-delà de la portée du règlement des transactions de base, cela devrait s’appliquer aux outils que nous utilisons pour construire ou compiler du code, et les développeurs et les utilisateurs devraient en être plus conscients pour encourager l’intégrité entre les projets.
Nous pouvons éviter toute déception en adoptant une vision holistique de l’espace ZK – un avenir qui promet de permettre une vérification sans confiance de presque tout. Les constructeurs doivent comprendre que ses capacités vont bien au-delà de l’évolutivité et de la sécurité.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Pourquoi les gens font-ils trop confiance à la technologie à connaissance nulle ?
Par Misha Komarov, Blockworks, compilé par Song Xue, Golden Finance
Le Web3 met tellement l’accent sur le concept de base de la technologie à connaissance nulle qu’il est maintenant devenu un fondement et le centre de chaque développement. Mais ses avantages en matière d’évolutivité, de sécurité et de confidentialité ne le rendent pas digne de confiance.
Ce que les gens ne réalisent pas, c’est que dans l’environnement Web3, la technologie zero-knowledge (ZK) est encore assez nouvelle et n’est pas sans défauts. Les développeurs s’attaquent activement aux problèmes actuels de la technologie ZK, mais la nature innovante de l’espace signifie qu’ils ont tendance à conceptualiser plus vite qu’ils ne peuvent construire.
Continuer à faire confiance à ZK sans bien comprendre ses problèmes techniques est dangereux pour un avenir Web3 durable. Avant de se fier aveuglément à cette technologie, nous devons l’examiner en profondeur et ses inconvénients potentiels. **
Il ne devrait pas y avoir de héros dans le Web3 – aucune technologie ne devrait être vénérée. **
Dans un avenir idéal, la technologie ZK jouera un rôle plus intégré dans toutes les activités on-chain. Cependant, la technologie existe actuellement presque comme un add-on ou un accessoire, plutôt que comme quelque chose qui est capable de prendre fondamentalement en charge l’exécution on-chain. ** Cela s’explique par le fait que les domaines et les produits en cours de développement sont encore relativement récents.
Mais le domaine de la technologie ZK s’est développé au point qu’il risque de se compliquer à l’excès. Il existe un fossé croissant entre les constructeurs ZK et les utilisateurs du Web3. **
Parmi les autres problèmes rencontrés par le développement technologique de ZK, citons l’optimisation des délais de mise sur le marché sans compromettre l’intégrité du projet. Les preuves et les circuits ZK manquent actuellement d’accessibilité car les développeurs doivent apprendre des langages spécifiques à un domaine (DSL) pour prouver davantage ces calculs.
Il s’agit d’un processus à forte intensité de connaissances, comme en témoigne le fait qu’il s’est écoulé près d’un an et demi entre le test pré-alpha de Scroll et le lancement du réseau principal. En prenant le temps de faire la bonne implémentation et la bonne revue de code, le délai de mise sur le marché de Scroll peut être entravé par un processus d’examen approfondi du code de circuit zkEVM mis en œuvre par le biais de certains zkDSL personnalisés liés à Halo2.
C’est un problème car seules quelques personnes dans le monde ont une connaissance directe de l’ADSL et de la cryptographie. Au fur et à mesure que de plus en plus de développeurs utilisent la technologie avancée ZK, nous devons nous assurer que chaque composant de la technologie ZK est vérifiable de manière indépendante.
Ensuite, il y a le défi de la configurabilité. Chaque mise à niveau nécessaire est en fin de compte une refonte complète du système nouvellement construit, et non une « mise à niveau » dans le sens où le développeur construit sur un framework existant.
Les projets qui prennent en charge ZK travaillent déjà sur des solutions qui simplifient le processus de construction pour les développeurs. Cela permettra de résoudre des problèmes clés, notamment la lenteur de la mise sur le marché, le coût de la génération de preuves en tant que partie indépendante, la configurabilité des circuits et la nécessité d’apprendre des langages cryptographiques spécifiques.
Il est essentiel de créer des moyens plus simples de compiler du code en circuits entièrement fonctionnels aussi facilement que possible pour garantir la composabilité des applications compatibles ZK. Des outils tels que les compilateurs peuvent rapidement vous aider à vérifier la fonctionnalité de votre code. Les développeurs peuvent également utiliser une variété de langages de codage pour développer des applications plus efficaces.
Continuer à se concentrer sur le travail essentiel qui a une incidence sur l’évolutivité et la sécurité sur d’autres questions en cours dans ce domaine. **Les lacunes de la technologie ZK sont ignorées simplement parce que l’industrie a désespérément besoin d’évolutivité et de sécurité, ignorant les lacunes du coût et de la complexité. **
La vérité est que la technologie ZK doit rendre les choses simples. Les développeurs devraient être en mesure d’utiliser la technologie même s’ils ne sont pas des experts en cryptographie ou en conception de circuits.
Les fournisseurs d’infrastructure ZK doivent créer des outils qui facilitent la création d’applications compatibles ZK et simplifient le processus de création pour les développeurs.
La rationalisation des procédures de production et la réduction des coûts liés à l’infrastructure sont un moyen de résoudre ces problèmes. Une autre approche possible consiste à fournir plus de ressources et de soutien, tels que des programmes éducatifs et des possibilités de mentorat, aux développeurs qui cherchent à entrer dans le domaine.
En fin de compte, même avec la technologie ZK, ne vous contentez pas de faire confiance, mais de vérifier. **
Cela va au-delà de la portée du règlement des transactions de base, cela devrait s’appliquer aux outils que nous utilisons pour construire ou compiler du code, et les développeurs et les utilisateurs devraient en être plus conscients pour encourager l’intégrité entre les projets.
Nous pouvons éviter toute déception en adoptant une vision holistique de l’espace ZK – un avenir qui promet de permettre une vérification sans confiance de presque tout. Les constructeurs doivent comprendre que ses capacités vont bien au-delà de l’évolutivité et de la sécurité.