Solana active le processus de transaction V1 pour atteindre un volume de transactions trois fois supérieur, et permet l’utilisation des preuves ZK.

• Solana active la Transaction V1 le 9 septembre, augmentant la taille maximale des transactions de 1 232 octets à 4 096 octets.Soutenir les preuves d’information nulle atomiqueEt les signatures BLS.
• Cette mise à niveau permet au réseau de correspondre aux pages de mémoire de quatre kilo-octets utilisées dans le matériel des validateurs.Éliminer les contraintes liées aux paquets héritésCela a réduit la complexité des transactions.
• Le framework de transferts de token natif de Wormhole permet à la offre circulante de Dogecoin, s’élevant à 35 milliards de dollars, de se transférer nativement vers Solana.Évitant les liquidités fragmentéesdes ponts multiples.
• Kamino Finance introduit un nouveau marché de prêts sur Solana qui accepte des Zcash (ZEC) comme garantie pour les prêts en USDC.Utiliser des ensembles de risques isolés.Pour atténuer la volatilité.
• Les fournisseurs d’infrastructures et les indexateurs doivent mettre à jour leurs systèmes rapidement afin de pouvoir analyser correctement le nouveau format des transactions et les configurations des frais de priorité.Pour éviter les erreurs de données.

Solana met en œuvre une amélioration structurelle de son format de transactions. La version V1 des transactions est activée sur le mainnet le 9 septembre. Cette modification augmente considérablement la taille maximale d’une transaction, passant de 1 232 octets à 4 096 octets. Ce nouveau limite est défini par les propositions SIMD-0296 et SIMD-0385. Cela permet au réseau de se conformer aux pages de mémoire de quatre kilooctets utilisées dans l’équipement moderne des validateurs. Cette évolution résout un problème ancien qui limitait les opérations cryptographiques complexes. Auparavant, le limite de 1 232 octets était déterminé pour permettre l’intégration dans les paquets Internet de 1 280 octets. La nouvelle capacité permet donc aux preuves de zéro connaissances, aux signatures BLS et aux portefeuilles multisig volumineux de s’intégrer dans des transactions atomiques. Cette atomicité au niveau du protocole remplace les méthodes précédentes qui dépendaient des bundles Jito pour regrouper les transactions. Une seule transaction v1 peut être annulée sans problème si un seul étape échoue, ce qui offre des garanties plus solides pour les opérations financières décentralisées complexes. L’amélioration est activée via des portes de fonctionnement aux points de fin des époques. Les formats de transactions de version v0 restent valables, ce qui signifie qu’il n’est pas nécessaire de procéder à un fork ou à une migration des utilisateurs.

Comment le nouveau format affecte-t-il les développeurs et l’infrastructure ?

La transition vers la Transaction V1 entraîne des changements importants pour les développeurs et les fournisseurs d’infrastructure blockchain. Le nouveau format supprime les tables de recherche d’adresses, au profit d’adresses intégrées directement dans la transaction. Ce changement structurel exige que toutes les adresses des comptes soient indiquées directement à l’intérieur de l’enveloppe de transaction. Bien que cela augmente la taille de l’enveloppe, l’analyse technique indique que…90 % des transactions sélectionnéesLe fichier serait de moins de 1 400 octets lors de la conversion de v0 en v1. Les développeurs doivent déterminer si l’augmentation de la taille du fichier justifie la perte de la compression ALT pour des cas d’utilisation spécifiques comme les échanges entre plusieurs pools.

Les fournisseurs d’infrastructures doivent respecter des exigences de compatibilité immédiates. Les fournisseurs de calls de procédure à distance doivent définir leur version maximale de transaction supportée à une seule, afin d’éviter les erreurs de requête. Les services d’indexation, d’exploration et d’analyse doivent mettre à jour la manière dont ils récupèrent les limites de ressources. La version V1 stocke les limites de calcul et les paramètres liés aux frais de priorité dans une configuration de transaction dédiée, plutôt que dans les instructions traditionnelles liées au ComputeBudget. Les services obsolètes risquent de présenter des informations incorrectes, comme indiquer des frais de priorité nuls lorsque les utilisateurs les ont payés. Les consommateurs de Geyser et de gRPC doivent vérifier l’existence du champ Message.config, plutôt que des indicateurs de version, pour pouvoir identifier correctement les transactions de version V1. Les fournisseurs doivent mettre à niveau vers Agave v4.2.2 ou v4.3.0-beta.3 afin de pouvoir gérer correctement le trafic de version V1.

Quelles sont les implications pour les actifs entre chaînes et le DeFi ?

Solana étend également son écosystème d’actifs grâce à des intégration entre chaînes de blocs majeures. Le Dogecoin est arrivé sur Solana grâce au système de transfert de tokens natifs de Wormhole et au portail de liquidité Sunrise. Cette intégration couvre l’ensemble de la quantité de Dogecoin en circulation, soit 35 milliards de dollars. C’est l’une des plus grandes transferts entre actifs différents de l’histoire. Contrairement aux méthodes traditionnelles qui bloquent les actifs et créent des versions synthétiques, le système de transfert de tokens natifs permet de transférer directement les tokens eux-mêmes. Cette approche utilise des preuves de zéro connaissances pour vérifier les transferts, tout en préservant la responsabilité de l’émetteur concernant la politique de supply et les métadonnées. Le portail Sunrise attribue un adresse de mint unique aux actifs reçus, ce qui garantit qu’il y a une seule version canonique de Dogecoin sur Solana.Réduit la fragmentation de la liquidité etDifférentes erreurs de tarification qui surviennent souvent lorsque les actifs arrivent par plusieurs ponts.

Le paysage des protocoles évolue simultanément pour soutenir les actifs non natifs. Kamino Finance a lancé un nouveau marché de prêts sur Solana, qui accepte le Zcash comme garantie. Les utilisateurs peuvent placer du Zcash pour emprunter du USDC, ou utiliser le produit Multiply de Kamino pour automatiser des stratégies d’utilisation de levier. Cela implique de prêter du USDC, de le convertir en Zcash, et de redépôt cet actif en une seule transaction. Kamino intègre le Zcash dans son architecture de prêt isolée, afin de limiter les risques dans des pools spécifiques. Cette structure permet au protocole de définir des ratios de prêt par rapport à la valeur de l’actif adaptés à la volatilité de celui-ci. Cela évite les risques de propagation des risques vers la liquidité principale du protocole en cas de baisse soudaine.

Ces développements font de Solana un hub à haute performance pour les transactions avancées et les opérations financières décentralisées complexes. La réseau se prépare pour l’amélioration suivante du consensus Alpenglow, qui vise à obtenir une finalité en 100–150 ms. Cette amélioration remplace TowerBFT par Votor et Rotor, afin d’améliorer la fiabilité des transactions pour les bourses et les prestataires de paiement. La combinaison de capacités de transaction plus élevées, de flux d’actifs interchainés natifs et de marchés de prêts sophistiqués renforce l’utilité de la plateforme pour les cas d’usage professionnels. Cependant, la concentration des flux d’actifs importants via un seul gestionnaire introduit des risques de centralisation que les investisseurs doivent surveiller. Le réseau doit également équilibrer l’utilisation accrue du bande passante due aux transactions plus importantes avec la volatilité possible des frais de priorité.