Présentation sur ZK Compression : Breakpoint 2024

ZK Compression : tout envoyer à zéro

Lorsque les développeurs commencent à travailler sur Solana, ils découvrent rapidement que si les calculs sont relativement peu coûteux, le stockage des données est cher. Par exemple, avec un SOL à 150 $, créer 1 000 comptes de jetons coûte environ 300 $, tandis que la création d’un million de comptes coûterait 300 000 $. La mise à l’échelle des applications pour une vaste base d’utilisateurs devient donc financièrement prohibitive, car ces coûts augmentent avec le prix du SOL. De plus, la croissance de l’état constitue un défi pour toutes les blockchains avec état. À mesure que de nouveaux comptes sont créés, des frais de location doivent être payés pour les maintenir, ce qui est coûteux. Solana compte actuellement plus de 500 millions de comptes, auxquels s’ajoutent environ un million de nouveaux comptes chaque jour.

La compression ZK résout ces problèmes en offrant :

• Des comptes mille fois moins chers
• Une solution à la croissance de l’état
• Une base pour les calculs ZK sur Solana

Compression de l’état + ZK

Pour comprendre la compression ZK, commençons par décomposer la compression de l’état, qui s’articule autour de cinq grandes étapes :

1. Des millions de comptes → « empreinte »
2. Stocker l’empreinte on-chain
3. Stocker l’historique des comptes dans le registre Solana
4. Mettre en cache le dernier état des comptes avec un indexeur
5. Vérifier l’état des comptes compressés à l’aide de l’« empreinte » on-chain

Nous commençons par compresser des millions de comptes Solana et par les hacher en une « empreinte » compacte. Cette empreinte est stockée dans un compte on-chain, tandis que l’ensemble des données sous-jacentes des comptes reste accessible dans le registre de Solana. Pour garantir la validité de ces comptes off-chain, nous utilisons un mécanisme de preuve qui vérifie leur intégrité à l’aide de l’empreinte on-chain. La dernière étape de ce processus utilise les SNARK à divulgation nulle de connaissance, qui alimentent le système de preuve chargé de vérifier l’intégrité de ces comptes.

Pourquoi ZK Compression ?

Plusieurs fonctionnalités clés font de la compression ZK une solution idéale pour la compression de l’état. Par exemple, les comptes compressés se comportent comme des comptes Solana standards, ce qui permet aux développeurs de tirer parti de leurs compétences et techniques de développement existantes avec une courbe d’apprentissage réduite. Cela diminue les obstacles à l’adoption et facilite l’utilisation de la compression ZK par les développeurs.

‍L’API exposée par l’indexeur reflète étroitement les appels RPC existants. Par exemple, la méthode getAccountInfo correspond directement à getCompressedAccount, et cette correspondance directe s’étend à toute l’API RPC. Cette cohérence simplifie l’intégration de la compression ZK aux outils et workflows Solana existants.

PDA compressées

L’une des fonctionnalités clés de ce système est sa prise en charge des adresses dérivées d’un programme (PDA) compressées. Les PDA sont des adresses de compte déterministes qui peuvent être dérivées de manière cohérente à partir d’une adresse de programme et d’une graine spécifiques. Les PDA compressées permettent d’éliminer les problèmes tels que les conditions de concurrence, les collisions d’adresses ou la création accidentelle de plusieurs comptes pour une même combinaison d’adresse de programme et de graine. Cette amélioration est l’une des principales raisons du passage du système existant de compression des comptes SPL à la compression ZK.

‍Avec une prise en charge complète de la compression ZK, l’impact potentiel sur Solana est considérable. Les PDA et la possibilité de composer des programmes permettent de créer des architectures plus complexes impliquant plusieurs programmes et différentes PDA, reproduisant ainsi l’expérience familière du développement d’applications traditionnelles. Tout cela peut être réalisé pour une fraction du coût, avec une réduction pouvant aller jusqu’à mille fois des dépenses liées aux comptes. Cette baisse spectaculaire des coûts ouvrira la voie à de nouveaux cas d’usage jusqu’alors inaccessibles en raison de coûts prohibitifs.

Améliorations de la composabilité

Tout s’exécute directement sur Solana : il ne s’agit ni d’un L2 ni d’un validium. La disponibilité des données est automatiquement assurée par le registre Solana, ce qui garantit une exécution vérifiable et entièrement composable.

‍Les preuves à divulgation nulle de connaissance réduisent la taille des preuves à une valeur constante de 128 octets, libérant davantage d’espace dans chaque transaction pour d’autres opérations. La composabilité est ainsi facilitée et d’autres activités bénéficient d’une plus grande flexibilité. La taille des preuves reste constante, quel que soit le nombre de comptes mis à jour, lus ou écrits dans une même transaction, ou le nombre d’inclusions ou d’exclusions à prouver. C’est essentiel, car les transactions Solana sont intrinsèquement petites (1,2 kilooctet). Une fonction de hachage différente était nécessaire pour les arbres de Merkle d’état afin d’obtenir des temps de génération de preuve rapides, raison pour laquelle nous ne pouvions pas utiliser le programme original de compression des comptes SPL.

Décompression

La décompression est une autre fonctionnalité clé. Elle évite tout verrouillage et permet une interopérabilité fluide entre les comptes « standards » et compressés. Tout compte Solana peut être compressé, ce qui vous permet de récupérer les frais de location. Vous pouvez également décompresser un compte compressé à tout moment et passer facilement d’une forme à l’autre. Par exemple, si vous avez un jeton compressé qui doit être échangé, vous pouvez simplement le décompresser et l’utiliser avec Jupiter pour effectuer l’échange.

La décompression permet de passer sans difficulté d’un état actif à un état inactif. Par exemple, si vous développez un jeu comprenant différents objets et cartes compressés, vous pouvez les décompresser pendant les combats pour permettre des changements d’état rapides, puis les recompresser afin d’enregistrer le résultat final, comme les modifications des points de vie. La concurrence au sein d’un même arbre pendant un slot présente certaines limites. Évitez la compression si vous devez mettre à jour le même compte plusieurs fois dans un bloc. Dans ce cas, il est préférable de décompresser définitivement ce compte afin qu’il fonctionne comme un compte on-chain standard. Par exemple, un compte de pool AMM serait mieux adapté à ce format, car son état doit être régulièrement mis à jour. Le système est suffisamment flexible pour interagir avec des comptes compressés et décompressés au sein d’une même transaction.

Cette solution entièrement généralisée ne se limite pas à un programme, une logique métier ou une application. Les comptes Solana peuvent être compressés à faible coût avec une prise en charge intégrée de l’indexation. La solution est entièrement open source, prête pour la production et adaptable à différents cas d’usage.

Jetons compressés

Les jetons compressés ne sont pas directement compatibles avec les plateformes d’échange et DeFi si celles-ci ne les prennent pas en charge. Ce problème peut toutefois être facilement résolu en décompressant le jeton compressé pour le convertir en jeton SPL standard, qui peut ensuite être utilisé dans la DeFi et sur les plateformes d’échange comme n’importe quel jeton standard. Cette flexibilité évite tout verrouillage et permet aux utilisateurs de passer des jetons compressés aux jetons standards selon leurs besoins. Les jetons compressés sont idéaux pour les applications inactives nécessitant des interactions moins fréquentes, tandis que les comptes de jetons standards conviennent mieux à l’état actif ou aux actifs fréquemment utilisés. L’un des principaux avantages de ce système réside dans sa capacité à résoudre le problème de croissance de l’état en transférant les données d’état inactives vers un stockage compressé, afin de préserver tous les avantages tout en gérant l’état plus efficacement.‍

‍Dans notre version initiale, nous avons lancé des jetons compressés créés avec les mêmes outils que ceux utilisés pour toute application prenant en charge la compression. Le programme de jetons compressés est identique au programme de jetons Solana et offre la même expérience utilisateur pour un coût mille fois inférieur. Les extensions de jetons devraient être mises en ligne début 2025.

Grâce à des fonctionnalités comme la décompression, vous pouvez distribuer de grands volumes de jetons par airdrop, puis les décompresser rapidement lorsque vous en avez besoin pour des activités DeFi. Si les preuves à divulgation nulle de connaissance (ZK) sont souvent considérées comme le Graal des calculs coûteux, nous avons optimisé le processus pour que les transferts ressemblent à des transferts standards de jetons SPL, avec des temps de génération de preuve réduits à quelques millisecondes. La technologie ZK grand public et prête pour la production passe ainsi au premier plan, réduisant considérablement le coût de gestion des comptes de jetons.

Comment fonctionne ZK Compression ?

Le système global comprend cinq composants principaux : 

• Une forêt d’arbres d’état
• Light System Program
• Compressed Token Program
• Nœuds Forester
• Indexeurs (Photon)

Une forêt d’arbres d’état

Nous avons tout d’abord des arbres de Merkle d’état, que nous appelons la « forêt d’arbres de Merkle d’état ». Cette structure crée une empreinte cryptographique unique d’un ensemble de comptes, que nous pouvons stocker on-chain. Par exemple, si vous avez quatre comptes, vous pouvez les hacher de manière récursive pour former une structure d’arbre de Merkle.

Le hachage final de 32 octets situé au sommet fournit une garantie cryptographique de l’intégrité des données sous-jacentes de tous les comptes. Cela permet de vérifier facilement l’état de n’importe quel compte au sein de l’arbre de Merkle en le comparant à la racine d’état. Nous utilisons ici le terme « forêt », car il existe plusieurs arbres de Merkle, chacun doté de sa propre racine.

Comparaison avec la compression existante des comptes SPL

L’une des améliorations majeures de la compression ZK par rapport au programme existant de compression des comptes SPL est la possibilité de prouver qu’un élément d’état appartient à un arbre de Merkle donné, assurant ainsi une génération efficace des preuves dans les limites de taille des transactions Solana. Cela nous permet de prouver l’unicité d’une adresse donnée en gérant un arbre d’adresses, semblable à un arbre de Merkle d’état, mais doté d’une fonctionnalité supplémentaire : prouver l’inclusion dans une feuille prouve également l’exclusion d’une plage spécifique de nombres. Il est ainsi possible de gérer un espace d’adressage de 248 bits avec des arbres de Merkle beaucoup plus petits, tout en garantissant l’unicité des adresses.

M comptes peuvent être prouvés pour N arbres tout en conservant une taille de preuve constante de 128 octets, ce qui respecte parfaitement la limite de 1,2 ko des transactions Solana. La génération des preuves, qui s’effectue off-chain, est plus coûteuse que dans le programme existant de compression des comptes SPL. En revanche, la vérification des preuves, qui s’effectue on-chain, reste constante et se révèle généralement moins coûteuse que le programme de compression existant.

Light System Program et Compressed Token Program

Le protocole implique deux programmes clés. Le Light System Program est un contrat on-chain qui reproduit le Solana System Program. Il interagit avec l’arbre de Merkle, applique le modèle de compte Solana standard et vérifie l’unicité des PDA. Le Compressed Token Program reproduit le programme de jetons SPL et applique la structure de données SPL au sein du modèle de compte compressé.

Nœuds Forester

Les nœuds Forester sont chargés de gérer cette forêt légère. Lorsque vous mettez à jour un compte compressé, un nouvel état de compte est ajouté à l’arbre, tandis que l’ancien état est remis à zéro ou invalidé.

Cette approche a deux conséquences majeures. Premièrement, toute mise à jour de l’état entraîne une modification de la racine à mesure que les changements se propagent jusqu’au sommet de l’arbre de Merkle inversé. Deuxièmement, les arbres se remplissent progressivement et finissent par atteindre leur capacité maximale. C’est là qu’intervient la forêt d’arbres légers.

Les nœuds Forester sont chargés de maintenir la racine d’état. Ils mettent à jour la racine d’état de manière asynchrone et gèrent le remplacement des arbres d’état pleins. L’exploitation d’un nœud Forester pour vos propres arbres d’état est sans autorisation et fonctionne de manière similaire à l’exploitation d’un RPC, ce qui permet à chacun de gérer ses propres mises à jour d’état. En tant que développeur d’applications, vous avez tout intérêt à maintenir votre état compressé, ce qui vous incite naturellement à veiller à la bonne gestion de vos arbres d’état. Vous pouvez choisir d’exécuter votre propre nœud en auto-hébergement ou de payer un fournisseur pour s’en charger.

Photon

L’indexeur Photon est une solution open source conçue pour suivre et gérer les mises à jour, les créations, les mutations et les autres événements liés aux comptes compressés sur la blockchain. Il écoute l’activité on-chain et met en cache l’état actuel de ces comptes. Il génère également des preuves cryptographiques utilisables pour la vérification ou la mutation des données.

‍L’indexeur Photon prêt pour la production intègre d’importantes améliorations fondées sur les enseignements tirés des versions précédentes de la compression. Son objectif est d’être simple d’utilisation et accessible, que vous soyez développeur indépendant, entreprise ou fournisseur RPC.

Le développement local a été considérablement simplifié. Un outil CLI en un clic s’intègre de manière fluide à votre configuration locale. Un explorateur destiné aux développeurs est également disponible. Il fournit une interface visuelle permettant de consulter les comptes compressés, de suivre leurs modifications et d’examiner l’historique des transactions.

Photon génère des instantanés quotidiens, accélérant ainsi le développement et le déploiement. Au lieu de tout réindexer depuis le bloc de genèse, les développeurs peuvent partir d’un instantané et réduire les temps de démarrage et d’initialisation à 15 minutes ou moins. Ces instantanés facilitent également la réplication : si un fournisseur RPC cesse de prendre en charge la compression, vous pouvez facilement récupérer un instantané et exécuter l’indexeur de manière indépendante. Le risque de perte de données est réduit grâce aux instantanés, qui peuvent être stockés dans des solutions décentralisées comme FileCoin.

Avec Photon, vous pouvez choisir de n’indexer qu’un sous-ensemble des données, ce qui réduit considérablement les exigences matérielles et la taille de la base de données. Vous pouvez le faire avec SQLite à l’aide d’une seule commande CLI. Si vous êtes fournisseur RPC, vous pouvez aussi choisir d’indexer l’intégralité du jeu de données. Photon est disponible avec tous les forfaits Helius. Vous pouvez également l’exécuter de manière indépendante ou demander à un autre fournisseur de le proposer.

Par des développeurs, pour les développeurs

Nous nous consacrons entièrement aux développeurs et travaillons activement sur trois améliorations majeures spécialement conçues pour optimiser leur expérience.

Web3.js pour la compression

Le SDK est conçu pour fonctionner comme Solana web3.js, tout en prenant entièrement en charge la compression. Pour lancer un transfert de jetons compressés, vous récupérez d’abord vos comptes de jetons compressés, puis vous les utilisez pour obtenir une preuve de validité auprès de votre RPC ou d’un nœud de preuve dédié. Vous créez ensuite les instructions comme vous le feriez avec le programme de jetons SPL, en indiquant ce que vous souhaitez envoyer, la quantité, la frappe et le destinataire, afin de créer une transaction Solana standard.

‍Configuration complète du développement local

Nous proposons un validateur de test préconfiguré avec tout le nécessaire pour le développement local, y compris tous les programmes requis, l’indexeur Photon et un nœud de preuve local. Les développeurs bénéficient ainsi d’un processus de configuration simplifié.

Macros Anchor

Pour les personnes qui connaissent le développement de programmes Solana avec Anchor, notre objectif est de rendre le travail avec des comptes compressés aussi fluide qu’avec des comptes standards. Si vous avez déjà écrit un programme Anchor, vous retrouverez immédiatement une expérience de développement familière. Les macros Anchor sont encore en cours de développement.

Airship

Airship permet aux développeurs d’exploiter dès aujourd’hui la compression ZK grâce à un outil d’airdrop massif de jetons, à la fois simple et économique. Il propose une interface utilisateur et une CLI. Comme il est entièrement open source, les développeurs peuvent le dupliquer et le modifier selon leurs besoins. À mesure que davantage de développeurs distribueront des jetons compressés par airdrop, l’écosystème commencera à les adopter dans différentes applications. Toutefois, si une conversion immédiate est souhaitée, les développeurs peuvent décompresser les jetons sans attendre. Airship est donc dès aujourd’hui un outil d’airdrop prêt à l’emploi pour les jetons standards.

‍L’outil prend automatiquement en charge les airdrops destinés aux détenteurs de Solana mobile, de jetons spécifiques ou de collections de NFT. Si vous disposez d’une liste de destinataires prégénérée, vous pouvez également importer un fichier CSV et préciser le jeton ainsi que la quantité à distribuer. La CLI et l’interface utilisateur vous permettent toutes deux de reprendre votre airdrop depuis le dernier état enregistré si vous rencontrez un problème, comme une perte de connexion Internet. Cette fonctionnalité est particulièrement utile pour les airdrops importants, qui peuvent prendre 30 à 45 minutes lorsque des jetons sont distribués à une longue liste d’adresses.

Un nouvel espace de conception pour les applications

La compression ZK résout le problème de croissance de l’état en ne stockant dans la mémoire du validateur actif que le hachage racine final de tous les comptes. Cette approche atténue efficacement les problèmes de croissance de l’état. De plus, la compression ZK ouvre de nouvelles possibilités de conception pour les applications. Voici quelques cas d’usage potentiels :

• Compresseurs de jetons SPL
• Un milliard de memecoins
• Marchés prédictifs pour les publications Twitter
• PDA d’identification pour les nœuds des réseaux DePin
• Calcul et distribution vérifiables des récompenses
• Ponts minimisant la confiance
• Protocoles d’identité ZK

La documentation présente d’autres idées.

La compression ZK est disponible dès aujourd’hui sur le mainnet et le devnet ! Pour commencer, consultez notre documentation et suivez les exemples. Nous organisons également un hackathon avec jusqu’à 45 000 $ de prix.

Si vous souhaitez approfondir vos connaissances sur ZK, consultez nos précédents articles du blog Helius pour découvrir en détail les principes fondamentaux des preuves à divulgation nulle de connaissance et leurs applications sur Solana.

‍