Co-fondateur de Solana : Quelles sont les solutions pour la croissance de l'état de Solana ?
TechFlow SélectionTechFlow Sélection
Co-fondateur de Solana : Quelles sont les solutions pour la croissance de l'état de Solana ?
Doit gérer l'état et la mémoire dans les limites du matériel actuel.
Dédié à des analyses Web3 approfondiesRédaction : toly, cofondateur de Solana
Traduction : Felix, PANews
Environ un million de nouveaux comptes sont ajoutés à Solana chaque jour. L'état total atteint désormais plus de 500 millions, et la taille des snapshots est d'environ 70 Go. Bien que ces chiffres soient parfaitement gérables grâce aux améliorations matérielles, l'objectif du runtime SVM est d'offrir un accès au matériel le moins coûteux possible. Pour y parvenir, il faut impérativement gérer l'état et la mémoire dans les limites actuelles du matériel.
Bande passante PCI
À partir de 2024, la bande passante PCI la plus récente peut atteindre un débit compris entre 0,5 Tbs et 1 Tb, soit entre 64 Go/s et 128 Go/s. Cela peut sembler élevé, mais si une transaction lit/écrit 128 Mo, une bande passante PCI de 128 Go/s limiterait le TPS de la chaîne à environ 1 000. En pratique, la majorité des transactions accèdent à des données récemment chargées et mises en cache dans la RAM. La conception idéale devrait permettre de charger 1 000 transactions avec 128 Mo de nouvel état, ainsi que 10 000 ou plus de transactions lisant et écrivant dans l’état mis en cache.
Index des comptes
La création d'un nouveau compte nécessite de prouver que ce compte n'existe pas déjà. Ceci est généralement effectué automatiquement sur chaque validateur, car chacun possède un index complet de tous les comptes valides existants. Même si les données du compte ne sont pas stockées localement, seulement leur hachage, 500 millions de comptes représentent 32 octets pour la clé + 32 octets pour le hachage des données, soit 64 octets par entrée, donc 32 Go au total. C’est déjà suffisant pour justifier une séparation claire entre RAM et disque.
Taille du snapshot
Au-delà d'une certaine taille de snapshot, si une partie du réseau subit une panne matérielle, le temps nécessaire pour redémarrer un système à froid pourrait rallonger considérablement le temps de redémarrage dans le pire des cas. Bien que cette limite évolue quotidiennement avec les progrès du matériel et de la bande passante, et que Solana n'en soit pas encore proche, elle existe à tout moment donné.
Résumé
La mémoire et le disque ont des caractéristiques et des limites de performance différentes. Si SVM ne fait pas la distinction, les transactions doivent être tarifées selon le scénario le plus défavorable, ce qui limite inutilement les performances. Pendant l’exécution des transactions, toutes les clés de compte doivent être disponibles au minimum, et le nombre total de comptes affecte l'utilisation de la bande passante PCI entre la RAM et le disque. La taille des snapshots ne peut pas croître indéfiniment. La solution idéale serait :
-
Permettre d’insérer davantage de transactions dans un bloc sans consommer de ressources PCI
-
Gérer la taille totale de l'index et celle des snapshots
Chilly, Avocado, LSR. De mauvais noms sont souvent le signe d’un excellent design logiciel. Les ingénieurs d’Anza et Firedancer ont conçu la solution suivante.
Chilly
Le cache du runtime des comptes est géré de manière déterministe par toutes les instances. À haut niveau, il s'agit d'un cache LRU (Least Recently Used) pour l'accès à l'état. Pendant la construction et la planification des blocs, cette implémentation peut facilement vérifier les comptes sans avoir à verrouiller ou itérer sur le cache LRU. Le cache est implémenté via un mécanisme de compteur très simple.
-
Le nombre total d'octets chargés est suivi comme Bank::loaded_bytes:u64
-
Chaque compte est marqué avec un compteur courant account::load_counter:u64 lorsqu'il est utilisé
-
Lors du chargement d'un compte, si Bank::loaded_bytes - Account::load_counter > CACHE_SIZE, le compte est considéré comme "froid", et sa taille est comptabilisée selon la limite LOAD_LIMIT par bloc
-
Les nouveaux comptes ont load_counter = 0, donc tous les nouveaux comptes sont froids
-
Le planificateur du leader utilise LOAD_LIMIT comme seuil, similaire à la limite CU de verrouillage d'écriture
L'élégance de cette conception réside dans son intégration naturelle avec le planificateur actuel. Les utilisateurs n'ont qu'à se soucier de leurs frais prioritaires. Le planificateur doit résoudre un problème de type « sac à dos » en incluant toutes les transactions dont les charges restent en dessous de LOAD_LIMIT et des limites de verrouillage d'écriture. Les transactions à plus haute priorité peuvent être chargées en premier et utiliser LOAD_LIMIT. Une fois cette limite atteinte, toutes les autres transactions peuvent toujours être incluses dans le bloc. Ainsi, les validateurs peuvent maximiser la localité de cache des transactions.
Avocado
Avocado se compose de deux parties : la compression d'état et la compression d'index. On remplace d'abord les données du compte par leur hachage, puis on migre l'index des comptes vers un Binary Trie / Patricia Trie. Un nouveau compte doit fournir une preuve qu’il n’existe pas déjà dans le « trie ».
Compression d'état
La conception globale est la suivante :
-
Durant l'allocation, chaque compte est lié à X lamports par octet.
-
Si X < prix économique minimal actuel, le compte reste en mémoire et sera compressé
-
La compression est un processus multi-étapes s'étalant sur une époque
-
Les données du compte sont remplacées par leur hachage (data)
-
La clé du compte reste présente dans l'état
-
Toute transaction référençant un compte compressé échoue
-
La décompression nécessite de téléverser des données similaires à celles d’un chargeur
-
Le coût de décompression devrait être équivalent à celui de l’allocation d’un nouveau compte
On estime que 75 % des comptes n’ont pas été accédés pendant plus de 6 mois et ne le seront probablement jamais. Leur compression permettrait d’économiser 50 % de la taille du snapshot.
Compression d'index
Ce problème est plus difficile à résoudre. Même avec la compression d'état, les validateurs possèdent toujours tous les comptes potentiellement valides du système. Créer un nouveau compte nécessite d'interroger cette base de données. Le coût de stockage de cette base est élevé pour les validateurs, tandis que le coût de création d'un nouveau compte est faible pour les utilisateurs. Il faut garantir qu'une nouvelle clé privée n'entre pas en conflit avec un compte existant.
Binary Trie mining
-
Le Binary Trie est suivi comme partie intégrante du snapshot
-
Les validateurs souhaitant obtenir des SOL supplémentaires peuvent créer une transaction supprimant des paires clé-valeur (kv) de comptes compressés de l’état et les ajoutant au Binary Trie
-
Les utilisateurs peuvent retirer les kv du Trie lors de la décompression, inversant ainsi l’opération (ceci pourrait nécessiter une opération atomique durant la décompression afin de faciliter la gestion en arrière-plan des comptes compressés)
-
Pour les validateurs, quelle que soit la quantité de paires kv présentes, la taille de la racine du Trie reste constante
-
Avec des zkp, chaque transaction peut compresser environ 30 comptes
-
En supposant une seule transaction par bloc, la compression de 500 millions de comptes prendrait environ 80 jours
L'élément clé ici est que seul le validateur effectuant cette opération reçoit une récompense, et tous les validateurs ne sont pas tenus de la réaliser. Si tous les validateurs devaient l'exécuter, ils devraient tous maintenir le contenu actuel du Binary Trie, ce qui impliquerait que tout l’état doive faire partie du snapshot. Les validateurs souhaitant conserver l’état complet devraient envoyer une transaction pour compresser N comptes de l’index vers le Trie.
Preuve de nouveau compte
Pour créer un nouveau compte, l'utilisateur doit prouver que ce compte n'existe pas dans le Trie. Les validateurs conservant l’état complet peuvent générer une preuve d’absence du compte dans le Trie. Cela impose une charge aux utilisateurs, qui doivent constamment être connectés à des fournisseurs d’état volumineux pour générer ces preuves.
Sinon, l’utilisateur peut prouver que son compte a été créé à l’aide du hachage PoH le plus récent. La méthode la plus simple pour supporter cela est :
-
Générer une nouvelle PKI
-
L’adresse du compte est définie comme hash(récemment PoH hash, PKI::public_key)
Étant donné que les comptes du Trie doivent d’abord subir une compression d’état, ce qui prend une époque complète, aucun compte dans le Trie ne peut utiliser le hachage PoH le plus récent pour générer son adresse.
Une autre approche possible consiste à ce que la création de la PKI elle-même fournisse une preuve que la clé privée a été générée via hash(secret caché par l’utilisateur, récent PoH hash).
LSR
Lightweight Simple Rent, aussi appelé Less Stupid Rent. Comment tarifer le coût de création d’un nouveau compte, et comment garantir que les anciens comptes abandonnés soient finalement compressés, réduisant ainsi la charge globale du système et le coût pour les nouveaux utilisateurs ?
Il faut rétablir un système de loyer (Rent). Le Rent signifie que les comptes actifs doivent payer un certain montant (X dollars par octet par jour), comme les comptes AWS payent des frais de stockage.
Courbe de tarification du taux de Rent
RentRate = K*(taille_état)^N
Quelle que soit la taille actuelle de l’état, si elle est petite, le taux doit être bas ; s’il s’approche de la limite du snapshot, le taux doit être très élevé.
Prix minimal de liaison pour allocation
Un compte doit exister au minimum pendant une époque. L’allocation doit placer le compte en état « chaud ». Un compte chaud doit rester présent pendant la période de cache.
Garantie du nouveau compte = Nombre de slots par époque * RentRate * Taille_du_compte
Le solde du nouveau compte doit contenir au moins ce nombre de lamports pour être créé.
Brûlage des comptes chauds
lruturnverrate = durée moyenne pendant laquelle un compte reste dans le cache LRU, avec un maximum d’une époque. Cette valeur peut être une constante ou calculée hors chaîne, puis publiée dans SVM comme une constante médiane pondérée par les participations.
Compression
Lorsque (slot_actuel - slot_création_compte) * RentRate * taille_compte > lamports_compte, le compte est compressé et tous ses lamports sont brûlés.
La solution ci-dessus devrait rendre l’état peu coûteux, car avec le temps, les comptes inutilisés verront leurs lamports atteindre zéro et seront compressés. Les frais liés aux données diminueront, et même les frais d’index seront réduits, ce qui réduira la taille totale de l’état. Réduire la taille de l’état diminue également le coût super-quadratique des allocations.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
