Aleo: Blockchain de protection de la vie privée basée sur les zk-SNARKs

Aleo est un projet de Blockchain dédié à la protection de la vie privée, qui utilise la technologie des zk-SNARKs pour offrir une plus grande confidentialité et évolutivité. La philosophie fondamentale du projet est de permettre aux utilisateurs de vérifier leur identité et de traiter des données tout en protégeant leurs données personnelles.

Aperçu du projet

Protection de la vie privée

La technologie de base d'Aleo est les zk-SNARKs ( ZKPs ), permettant l'exécution des transactions et des contrats intelligents tout en préservant la vie privée. Par défaut, les détails des transactions tels que l'expéditeur et le montant sont cachés. 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.

Les principaux composants comprennent :

1. Langage de programmation Leo : un langage spécialement conçu pour le développement d'applications zk-SNARKs (ZKApps), réduisant les exigences en connaissances cryptographiques pour les développeurs.

2. snarkVM et snarkOS : snarkVM permet l'exécution de calculs hors chaîne, tandis que la chaîne vérifie uniquement les résultats, ce qui améliore l'efficacité. snarkOS garantit la sécurité des données et des calculs, et prend en charge l'exécution de fonctionnalités sans autorisation.

3. zkCloud : fournit un environnement de calcul hors chaîne sécurisé et privé, prenant en charge l'interaction de programmation entre utilisateurs, organisations et 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. Les développeurs peuvent déployer des applications dans le registre des programmes d'Aleo, sans dépendre de tiers, réduisant ainsi les risques de la plateforme.

évolutivité

Aleo adopte une méthode de traitement hors chaîne, où les transactions sont d'abord calculées sur l'appareil de l'utilisateur, puis seuls les résultats de vérification sont téléchargés sur la Blockchain. Cette méthode améliore considérablement la vitesse de traitement des transactions et la scalabilité du système, évitant ainsi les problèmes de congestion du réseau et de frais élevés.

mécanisme de consensus

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

Principales caractéristiques :

1. Finalité rapide des Blocs : assurer que chaque Bloc généré soit immédiatement confirmé, améliorant ainsi la stabilité des nœuds et l'expérience utilisateur.

2. Garantie de décentralisation : Séparer la production de blocs et la génération de coinbase, les validateurs sont responsables de la génération de blocs, 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 partagent les récompenses de bloc ; encourager les prouveurs à devenir validateurs en mettant en jeu des jetons, afin d'améliorer le degré de décentralisation et la puissance de calcul du réseau.

Aleo permet aux développeurs de créer des applications sans restriction de gas, ce qui le rend particulièrement adapté aux applications nécessitant un fonctionnement prolongé, comme l'apprentissage automatique.

Derniers développements

Aleo lancera son réseau de test incitatif le 1er juillet, voici quelques informations importantes :

1. La proposition ARC-100 a été adoptée, impliquant des mesures de conformité et de sécurité.

2. Le programme d'incitation des validateurs débutera le 1er juillet et se poursuivra jusqu'au 15 juillet, distribuant 1 million de points Aleo en tant que récompense.

3. L'offre initiale est de 1,5 milliard de jetons, l'offre initiale en circulation est d'environ 10 %.

4. Testnet Beta subira une dernière réinitialisation du réseau, ajoutant ARC-41 et une nouvelle fonctionnalité de puzzle.

5. Le gel du code est terminé.

6. Plan d'expansion des nœuds de validation : initialement 15, objectif d'atteindre 50 dans l'année, et enfin 500. Devenir un délégué nécessite 10 000 jetons, devenir un validateur nécessite 10 millions de jetons, ces montants diminueront progressivement.

Analyse de l'algorithme Synthesis Puzzle

Aleo a récemment mis à jour l'algorithme puzzle, ne se concentrant plus sur la génération des résultats de preuve zk, mais plutôt sur la génération des données intermédiaires witness avant la preuve. Le nouvel algorithme s'appelle Synthesis Puzzle, et son cœur consiste à générer un EpochProgram commun pour chaque epoch, en construisant un circuit de preuve R1CS, produisant l'assignation R1CS correspondante (, c'est-à-dire witness ), qui est utilisé comme nœud feuille de l'arbre Merkle, calculant la racine Merkle et la convertissant en proof_target de la solution.

Processus principal:

1. Chaque calcul de puzzle est appelé nonce, construit à partir de l'adresse recevant la récompense de minage, de epoch_hash et du compteur aléatoire.

2. Dans chaque epoch, tous les prover calculent le même EpochProgram, où le nombre aléatoire généré par epoch_hash est échantillonné à partir de l'ensemble d'instructions.

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

4. Agréger le R1CS et l'input correspondants au EpochProgram, effectuer le calcul des témoins.

5. Convertir le witness en une séquence de nœuds feuilles d'arbre Merkle.

6. Calculer la racine Merkle et la convertir en proof_target de la solution, déterminer si elle satisfait le latest_proof_target de l'epoch actuel.

7. Dans un même epoch, il est possible de mettre à jour l'entrée de EpochProgram par l'itération du compteur pour effectuer plusieurs calculs de solution.

Cette mise à jour transforme le puzzle de la génération de proof à la génération de witness, la logique de calcul de la solution reste cohérente au sein de chaque epoch, mais les différences de logique de calcul entre les epochs sont assez importantes. Le nouvel algorithme abandonne les calculs MSM et NTT précédents, ce qui pose des défis pour l'optimisation GPU. En raison de la dépendance sérielle dans le processus de génération de witness, la mise en œuvre de la parallélisation est également confrontée à certaines difficultés.