Solana a réduit le temps de production d’un créneau de 300 ms à 250 ms : l’horloge en chaîne va environ 17% plus vite. Mais pour chaque créneau, la quantité de calcul et de données pouvant y être chargée diminue proportionnellement : le débit total ne progresse guère.
En langage moins “jargonneux”, imagine une gare qui passe l’intervalle de départ de 30 secondes à 25. Chaque train embarque toujours le même nombre de personnes. En une heure, la capacité transportée ne change pas ; seule la file sur le quai est moins serrée.
Le coût se reporte ailleurs. L’epoch passe à environ 30 heures : la fenêtre pour les signatures hors ligne et les validations différées devient plus courte. Les flux de tenue de marché et de custody doivent donc être recalés. Ici, on a modifié le rythme, pas la capacité.
Les gens qui font de l’infrastructure ont une habitude : on ajuste d’abord les paramètres avant de parler d’architecture, parce que quand les paramètres sont changés, on peut publier un communiqué le jour même. La partie difficile, elle, consiste à relever la limite maximale de ce qu’un bloc unique peut contenir : cela implique l’état, les coûts de stockage et le seuil des validateurs. C’est plus lent à changer et moins “sexy”.
Je ne crois pas trop à l’explication “17% de gain de vitesse”. Les chiffres sont justes : mis dans un tableau, ils sont même jolis. Mais ils répondent à la question de savoir si la réaction en chaîne est plus rapide, pas à celle de savoir si la chaîne peut en charger plus. Le volume total de la chaîne ne change pas : seule l’expérience évolue. Ce type de modification aide plutôt ceux qui font du trading à haute fréquence ; pour ceux qui se contentent d’une confirmation équitable, l’aide est moindre.
Ce qu’il faut surveiller, ce sont deux autres indicateurs : après la mise à niveau, le taux de transactions échouées baisse-t-il nettement, et les frais de priorité baissent-ils nettement ? S’ils baissent, c’est que régler le rythme a bien soigné le “bouchon”. S’ils ne baissent pas, alors on a seulement avancé l’aiguille, et le travail reste le même.
#SOL涨约10% #Solana
En langage moins “jargonneux”, imagine une gare qui passe l’intervalle de départ de 30 secondes à 25. Chaque train embarque toujours le même nombre de personnes. En une heure, la capacité transportée ne change pas ; seule la file sur le quai est moins serrée.
Le coût se reporte ailleurs. L’epoch passe à environ 30 heures : la fenêtre pour les signatures hors ligne et les validations différées devient plus courte. Les flux de tenue de marché et de custody doivent donc être recalés. Ici, on a modifié le rythme, pas la capacité.
Les gens qui font de l’infrastructure ont une habitude : on ajuste d’abord les paramètres avant de parler d’architecture, parce que quand les paramètres sont changés, on peut publier un communiqué le jour même. La partie difficile, elle, consiste à relever la limite maximale de ce qu’un bloc unique peut contenir : cela implique l’état, les coûts de stockage et le seuil des validateurs. C’est plus lent à changer et moins “sexy”.
Je ne crois pas trop à l’explication “17% de gain de vitesse”. Les chiffres sont justes : mis dans un tableau, ils sont même jolis. Mais ils répondent à la question de savoir si la réaction en chaîne est plus rapide, pas à celle de savoir si la chaîne peut en charger plus. Le volume total de la chaîne ne change pas : seule l’expérience évolue. Ce type de modification aide plutôt ceux qui font du trading à haute fréquence ; pour ceux qui se contentent d’une confirmation équitable, l’aide est moindre.
Ce qu’il faut surveiller, ce sont deux autres indicateurs : après la mise à niveau, le taux de transactions échouées baisse-t-il nettement, et les frais de priorité baissent-ils nettement ? S’ils baissent, c’est que régler le rythme a bien soigné le “bouchon”. S’ils ne baissent pas, alors on a seulement avancé l’aiguille, et le travail reste le même.
#SOL涨约10% #Solana
