Auteur : toly, co-fondateur de Solana
Compilé par : Félix, PANews
Environ 1 million de nouveaux comptes sont ajoutés à Solana chaque jour, et l'état total dépasse désormais les 500 millions, avec une taille d'instantané d'environ 70 Go. À mesure que le matériel s'améliore, ces chiffres eux-mêmes sont entièrement gérables, mais l'objectif du runtime SVM est de fournir l'accès le moins cher au matériel, et pour y parvenir, l'état et la mémoire doivent être gérés dans les limites matérielles actuelles.
Bande passante PCI
À partir de 2024, la dernière bande passante PCI peut atteindre des débits de 0,5 To à 1 To. Ou 64 Go à 128 Go par seconde. Bien que cela semble énorme, si un émetteur lit/écrit 128 Mo, une bande passante PCI de 128 Go/s limitera le TPS de la chaîne à environ 1 000. En fait, la plupart des émetteurs accèdent à la mémoire récemment chargée et mise en cache dans la RAM. Une conception idéale permettrait de charger 1 000 tx avec 128 Mo de nouvel état, plus 10 000 tx ou plus lisant et écrivant l’état mis en cache existant.
Index des comptes
La création d'un nouveau compte nécessite la preuve que le compte n'existe pas actuellement. Cela se fait généralement automatiquement sur chaque validateur, car chaque validateur dispose d'un index complet de tous les comptes actuellement actifs. Même si les données du compte ne sont pas stockées localement, juste le hachage des données, 500 millions de comptes représenteraient 32 octets de clé + 32 octets de hachage de données ou 64 octets par élément, soit 32 Go. Cela suffit pour assurer la séparation de la RAM et du disque.
taille de l'instantané
Pour certaines tailles d'instantanés, le temps requis pour démarrer à froid un nouveau système est suffisant pour prolonger le temps de redémarrage le plus défavorable en cas de panne matérielle sur une partie du réseau. Les choses changent chaque jour à mesure que la bande passante et le matériel s'améliorent, et Solana ne se rapproche pas de cette limite, mais cette limite existe à tout moment.
aperçu
La mémoire et le disque ont des caractéristiques de performances et des limitations différentes. Si SVM ne fait pas de différence, alors les transactions et les limites doivent être tarifées pour le pire des cas, limitant ainsi les performances. Au minimum, toutes les clés de compte doivent être disponibles pendant l'exécution de la transaction, et le nombre total de comptes aura un impact sur l'utilisation de la RAM et de la bande passante PCIi du disque. Les instantanés ne peuvent pas être arbitrairement volumineux. La solution idéale est :
Autoriser davantage de transmissions qui ne nécessitent pas de ressources PCI à être regroupées en morceaux
Gérer la taille totale de l'index et la taille de l'instantané
Chilly,Avocat,LSR. Une mauvaise réputation est souvent le signe d’une bonne conception logicielle. Les ingénieurs d'Anza et Firedancer ont proposé la solution suivante.
Froid
Le cache d'exécution du compte est géré de manière déterministe par toutes les instances. À un niveau élevé, il s'agit d'un cache LRU de l'état d'accès. Cette implémentation facilite la vérification des comptes pendant la construction et la planification des blocs, sans avoir besoin de verrouiller ou d'itérer le cache LRU. Le cache est implémenté à l'aide d'un mécanisme de compteur très simple.
Le total des octets chargés est suivi comme Bank::loaded_bytes:u64
Chaque compte est étiqueté avec le total cumulé actuel 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 un compte froid et sa taille est calculée en fonction du LOAD_LIMIT par bloc
Les nouveaux comptes ont un load_counter de 0, donc tous les nouveaux comptes sont des comptes froids
Le planificateur du leader traite LOAD_LIMIT comme un filigrane, similaire à la limite CU de verrouillage en écriture.
L’avantage de cette conception est qu’elle s’intègre naturellement dans les planificateurs actuels. Les utilisateurs n’ont qu’à se soucier de leurs frais prioritaires. Le planificateur doit gérer la mise dans le sac à dos de toutes les transmissions inférieures aux limites de LOAD_LIMIT et de verrouillage en écriture du compte. L'émission de priorité la plus élevée peut être chargée en premier et utiliser LOAD_LIMIT. Une fois cette limite atteinte, toutes les autres émissions peuvent toujours être mises dans un bloc. Par conséquent, le validateur peut maximiser l’atténuation de la localité du cache des txs.
Avocat
Avacado se compose de deux parties, la compression d'état et la compression d'index. Remplacez d'abord les données du compte par un hachage, puis migrez l'index du compte vers un Trie binaire/Patricia Trie. Les nouveaux comptes doivent fournir la preuve qu'ils ne sont pas dans le "trie".
compression d'état
La conception approximative est la suivante :
Lors de l'allocation, chaque compte est lié à X lamports par octet.
Si
La compression est un processus en plusieurs étapes qui s'étend sur une époque
Les données du compte sont remplacées par des hachages (données)
La clé de compte est toujours en état
Échec de la transaction faisant référence au compte compressé
La décompression nécessite le téléchargement de données similaires au chargeur
Le coût de la décompression doit être le même que le coût de l'attribution d'un nouveau compte
On estime que 75 % des comptes n’ont pas été consultés depuis plus de 6 mois et ne le seront probablement jamais. Leur compression permet d'économiser 50 % sur la taille de l'instantané.
Compression d'index
C'est un problème plus difficile à résoudre. Avec la seule compression d'état, le validateur possède toujours tous les comptes valides possibles dans le système. La création d'un nouveau compte nécessite de vérifier cette base de données. Le coût pour le validateur pour stocker cette base de données est élevé, mais le coût pour l'utilisateur pour créer un nouveau compte est faible. Assurez-vous que la nouvelle clé privée n'entre pas en conflit avec les comptes existants.
Extraction de Trie binaire
Binary Trie est suivi dans le cadre de l'instantané
Les validateurs qui souhaitent gagner du sol supplémentaire peuvent créer une transaction qui supprime les paires compte-kv compressées de l'état et les ajoute au Trie binaire.
Les utilisateurs peuvent faire cela à l'envers sans y être autorisés en supprimant le kv du Trie pendant la décompression (cela peut nécessiter des opérations atomiques sur la décompression pour faciliter la gestion des comptes de compression en arrière-plan).
Pour un validateur, la taille de la racine de Trie est constante quel que soit le nombre de paires kv qu'elle contient
En utilisant zkp, environ 30 comptes peuvent être compressés par transmission
En supposant qu'il n'y ait qu'un seul bloc par bloc, il faudrait environ 80 jours pour compacter 500 millions de comptes.
L’essentiel de ce processus est que les validateurs qui effectuent cette action seront récompensés, mais tous les validateurs ne sont pas tenus d’effectuer cette action. Si tous les validateurs devaient faire cela, alors tous les validateurs devraient conserver le contenu du Binary Trie actuel, ce qui signifie que l'état entier devrait faire partie de l'instantané. Un validateur qui souhaite conserver l'intégralité de l'état doit soumettre une transaction qui compresse les N comptes de l'index en un trie.
Nouveau justificatif de compte
Pour créer un nouveau compte, l'utilisateur doit prouver que le compte n'existe pas dans Trie. Un validateur qui gère l'intégralité de l'état peut générer des preuves que le compte n'est pas dans le Trie. Cela impose une charge aux utilisateurs, qui doivent toujours être connectés à un grand fournisseur public pour générer ces preuves.
Alternativement, les utilisateurs peuvent prouver que leur compte a été créé avec un hachage PoH récent. La façon la plus simple de prendre en charge cela est :
Générer une nouvelle PKI
L'adresse du compte est un hachage (hachage PoH le plus proche, PKI :: public_key)
Étant donné que les comptes du Trie doivent d’abord être compactés par l’État, cela nécessite une époque entière. Il est impossible pour un compte Trie d'utiliser un hachage PoH récent pour générer une adresse.
Une autre méthode qui pourrait être prise en charge est que la création de la PKI elle-même pourrait fournir une preuve que la clé privée a été créée avec un hachage (secret caché de l'utilisateur, hachage PoH récent).
LSR
Loyer simple léger, également connu sous le nom de loyer moins stupide. Comment évaluez-vous le coût d'attribution de nouveaux comptes et comment garantissez-vous que les anciens comptes abandonnés seront finalement compressés et réduiront la charge globale du système et le prix pour les nouveaux utilisateurs ?
Le système de loyer (Rent) doit être restauré. Le loyer signifie que les comptes dans leur état actuel doivent être facturés X $/octet/jour, tout comme les comptes sur AWS paient pour le stockage.
Courbe de liaison des taux de loyer
Taux de loyer = K*(state_size)^N
Quelle que soit la taille actuelle de l'état, le taux doit être faible s'il est petit, ou très élevé s'il est proche de la limite de l'instantané.
Allocation Prix Minimum de Cautionnement
Le compte doit exister depuis au moins une époque. Une attribution est requise pour faire passer le compte au statut Hot. Les comptes chauds doivent exister pendant la mise en cache.
Nouvelle obligation de compte = Epoch Slots * RentRate * Account::size
Les nouveaux comptes doivent avoir au moins autant de lamports dans leur solde avant de pouvoir être créés.
Graver un compte chaud
lruturnverrate = Temps moyen que chaque compte passe dans le cache LRU, maximum 1 époque. Cette valeur peut être une constante ou peut être calculée hors chaîne et signalée au SVM en tant que constante pondérée par la mise médiane.
compression
Lorsque (emplacement actuel - account::creation_slot) * RentRate * account::size > account::lamports, compressez le compte et brûlez tous les lamports.
La solution ci-dessus devrait rendre l'État bon marché, car au fil du temps, les comptes inutilisés finiront par atteindre lamborts 0 et seront compressés. Ainsi, la surcharge de données sera réduite, et même la surcharge d'indexation sera réduite, ce qui réduira la taille de l'état actuel. Réduire la taille de l’État réduira le coût de l’allocation superquadratique.