Aleo : confidentialité et évolutivité avec des preuves à divulgation nulle de connaissance

Aleo est un projet de blockchain axé sur la protection de la vie privée, réalisant une plus grande confidentialité et évolutivité grâce à la technologie zk-SNARKs (ZKP). Le concept central de ce projet est de permettre aux utilisateurs de s'authentifier et de traiter des données sans divulguer d'informations personnelles.

Cet article présentera un aperçu du projet Aleo et de ses dernières avancées, et fournira une analyse détaillée de son nouvel algorithme puzzle.

Résumé du projet

Confidentialité

Le cœur d'Aleo est constitué de zk-SNARKs ( ZKPs ), ce qui permet l'exécution des transactions et des contrats intelligents tout en préservant la confidentialité. Les détails des transactions des utilisateurs, tels que l'expéditeur et le montant de la transaction, sont cachés par défaut. Ce design protège non seulement la vie privée des utilisateurs, mais permet également une divulgation sélective lorsque cela est nécessaire, ce qui est particulièrement adapté au développement des applications DeFi. Ses principaux composants incluent :

1. Leo langage de programmation : adapté du langage Rust, spécialement conçu pour le développement d'applications à connaissance nulle (ZKApps), réduisant ainsi les exigences en matière de connaissances en cryptographie pour les développeurs.

2. snarkVM et snarkOS : snarkVM améliore l’efficacité en permettant d’effectuer des calculs hors chaîne et de les vérifier uniquement sur la chaîne. snarkOS assure la sécurité des données et des calculs et permet l’exécution de fonctions sans autorisation.

3. zkCloud : Fournit un environnement informatique hors chaîne sécurisé et privé qui prend en charge l’interaction programmatique entre les utilisateurs, les organisations et les DAO.

Aleo propose également un environnement de développement intégré (IDE) et un kit de développement logiciel (SDK), permettant aux développeurs de rédiger et de publier rapidement des applications ; de plus, les développeurs peuvent déployer des applications dans le registre de programmes d'Aleo sans dépendre de tiers, réduisant ainsi les risques liés à la plateforme.

évolutivité

Aleo utilise une approche off-chain, où les transactions calculent d’abord les preuves sur l’appareil de l’utilisateur, puis ne téléchargent que les résultats de la vérification sur la blockchain. Cette méthode améliore considérablement la vitesse de traitement des transactions et l’évolutivité du système, évitant la congestion du réseau et les frais élevés similaires à ceux d’Ethereum.

mécanisme de consensus

Aleo a introduit AleoBFT, qui est un mécanisme de consensus à architecture hybride, combinant la finalité instantanée des validateurs et la puissance de calcul des prouveurs. AleoBFT non seulement améliore le degré de décentralisation du réseau, mais renforce également la performance et la sécurité.

1. Finalité rapide des blocs : AleoBFT garantit que chaque bloc est immédiatement confirmé après sa génération, améliorant ainsi la stabilité des nœuds et l'expérience utilisateur.

2. Garantie de décentralisation : en séparant la production de blocs de la génération de coinbase, les validateurs sont responsables de la génération de blocs, tandis que les prouveurs effectuent les calculs de preuve, empêchant ainsi un petit nombre d'entités de monopoliser le réseau.

3. Mécanisme d’incitation : les validateurs et les prouveurs se partagent la récompense de bloc ; Les provers sont encouragés à devenir des validateurs en jalonnant des jetons, augmentant ainsi la décentralisation et la puissance de calcul du réseau.

Aleo permet aux développeurs de créer des applications sans gaz, ce qui le rend idéal pour les applications de longue durée telles que l’apprentissage automatique.

Dernières nouvelles

Aleo lancera un testnet incitatif le 1er juillet, et voici quelques mises à jour importantes :

1. Vote ARC-100 approuvé : la proposition "Meilleures pratiques de conformité pour les développeurs et opérateurs Aleo" ARC-100(, qui concerne les aspects de conformité, le verrouillage des fonds sur le réseau Aleo et les mesures de sécurité telles que les délais de dépôt, a été votée et approuvée. L'équipe procède aux ajustements finaux.

2. Programme d’incitation du validateur : Le programme sera lancé le 1er juillet pour valider le nouveau mécanisme de puzzle. Le programme se déroulera jusqu’au 15 juillet, période pendant laquelle 1 million de points Aleo seront distribués en récompense. Le pourcentage de points générés par un nœud déterminera sa part de récompense, et chaque validateur devra gagner au moins 100 jetons pour recevoir la récompense. Les règles spécifiques n’ont pas encore été finalisées.

3. Approvisionnement initial et approvisionnement en circulation : L'approvisionnement initial est de 1,5 milliard de jetons, l'approvisionnement en circulation initial est d'environ 10 %) n'est pas encore finalisé(. Ces jetons proviennent principalement des tâches de Coinbase)7500 millions(, qui seront distribués au cours des six premiers mois, tout en incluant des récompenses pour le staking, l'exécution de validateurs et les nœuds de validation.

4. Réinitialisation du Testnet Beta : C'est la dernière réinitialisation du réseau, après laquelle aucune nouvelle fonctionnalité ne sera ajoutée, le réseau sera similaire à la mainnet. La réinitialisation vise à ajouter ARC-41 et la nouvelle fonctionnalité puzzle.

5. Gel de code : le gel de code a été terminé il y a une semaine.

6. Plan d'expansion des nœuds de validation : le nombre initial de nœuds de validation est de 15, avec pour objectif d'atteindre 50 dans l'année et d'atteindre finalement 500. Devenir un délégué nécessite 10 000 jetons, devenir un validateur nécessite 10 millions de jetons, ces montants diminueront progressivement avec le temps.

Interprétation de l’algorithme du puzzle de synthèse

Aleo a récemment mis à jour la dernière version de l'algorithme puzzle. Le nouvel algorithme ne se concentre plus sur la génération des résultats de preuve zk, mais a supprimé le calcul de MSM et NTT, en se concentrant sur la génération des données intermédiaires witness avant la production de la preuve.

![Interprétation du dernier algorithme Synthesis Puzzle d'Aleo : à la pointe de la révolution de la confidentialité dans le Web3])https://img-cdn.gateio.im/webp-social/moments-fd98786228320367ac6fe8f41a965499.webp(

) processus de consensus

Au niveau du protocole de consensus, dans son processus, le prover et le validateur sont respectivement responsables de la génération du résultat de calcul solution et de la création de blocs ainsi que de l'agrégation et de l'emballage de la solution. Le processus est le suivant :

1. Prover calcule le puzzle pour construire une solution et la diffuser sur le réseau

2. Les transactions agrégées des validateurs et la solution pour le prochain nouveau bloc garantissent que le nombre de solutions ne dépasse pas la limite de consensus ###MAX_SOLUTIONS(

3. La légitimité de la solution doit être vérifiée en s'assurant que l'epoch_hash correspond au latest_epoch_hash maintenu par le validator, que le proof_target calculé correspond au latest_proof_target maintenu par le validator dans le réseau, et que le nombre de solutions incluses dans ce bloc est inférieur à la limite de consensus.

4. Une solution valide peut obtenir des récompenses de consensus.

) Synthesis Puzzle en détail

La dernière version du noyau d'algorithme est appelée Synthesis Puzzle, dont le cœur consiste à générer un EpochProgram commun fixe pour chaque epoch. En construisant un circuit de preuve R1CS pour l'entrée et l'EpochProgram, un R1CS assignment ###, c'est-à-dire un witness (, est produit et utilisé comme nœud feuille de l'arbre Merkle. Après avoir calculé tous les nœuds feuilles, la racine Merkle est générée et convertie en proof_target de la solution. Le processus détaillé et les spécifications pour construire le Synthesis Puzzle sont comme suit:

1. Chaque calcul de puzzle est appelé nonce, il est construit à partir de l'adresse recevant la récompense minière, de l'epoch_hash et d'un compteur aléatoire. Chaque fois qu'il est nécessaire de calculer une nouvelle solution, un nouveau nonce peut être obtenu en mettant à jour le compteur.

2. Dans chaque epoch, tous les prover de réseau doivent calculer le même EpochProgram, qui est échantillonné à partir de l'ensemble des instructions par un nombre aléatoire généré par le epoch_hash actuel. La logique d'échantillonnage est :

   • L'ensemble d'instructions est fixe, chaque instruction )instruction( contient une ou plusieurs opérations de calcul, chaque instruction a un poids et un compteur d'opérations prédéfinis.
   • Lors de l'échantillonnage, un nombre aléatoire est généré en fonction de l'epoch_hash actuel, et ce nombre aléatoire est utilisé pour obtenir des instructions à partir de l'ensemble d'instructions en fonction des poids et les classer par ordre, en cumulant le nombre d'opérations jusqu'à 97 avant d'arrêter l'échantillonnage.
   • Composer toutes les instructions dans un EpochProgram

3. Utiliser un nonce comme graine de nombre aléatoire pour générer l'entrée du EpochProgram

4. Agréger les R1CS et les inputs du EpochProgram correspondant, effectuer l'assignation de witness)R1CS pour le calcul.

5. Après avoir calculé tous les témoins, ces témoins seront convertis en une séquence de feuilles correspondantes de l'arbre Merkle, l'arbre Merkle étant un arbre Merkle K-ary à 8 branches de profondeur 8.

6. Calculer la racine Merkle et la convertir en proof_target de la solution, vérifier si elle satisfait le latest_proof_target de l'epoch actuel. Si c'est le cas, le calcul est réussi, soumettre l'adresse de récompense, l'epoch_hash et le counter nécessaires à la construction de l'entrée mentionnée ci-dessus comme solution et diffuser.

7. Il est possible de mettre à jour les entrées de l'EpochProgram par le biais d'un compteur itératif dans le même epoch pour effectuer plusieurs calculs de solution.

( les changements et les impacts du minage

Après cette mise à jour, le puzzle est passé de la génération de proof à celle de la génération de witness. La logique de calcul de toutes les solutions dans chaque epoch est cohérente, mais la logique de calcul entre les epochs est assez différente.

Cette mise à jour abandonne complètement les méthodes d'optimisation GPU largement utilisées dans le testnet précédent. De plus, le processus de génération du witness se produit lors de l'exécution d'un programme évoluant avec les changements d'epoch, où certaines instructions auront des dépendances d'exécution séquentielle, ce qui rend la mise en œuvre de la parallélisation assez difficile.