BTC

$64777.517

2.33%

ETH

$3160.053

2.18%

BNB

$592.457

1.88%

XRP

$0.531

1.05%

Connaissance

Qu'est-ce qui a causé la récente panne de Solana et que fait-on pour éviter une nouvelle congestion du réseau ?

4 mai 2022 - Autour 4 min minutes pour lire
solana

Quelle est la cause de la récente panne de Solana ?

Bots liés à un nouveau projet NFT basé sur Solana a entraîné une panne de réseau de sept heures, selon les développeurs du projet. La panne, qui a commencé vers 20h30 UTC samedi et s'est terminée dimanche à 03h30 UTC, a été causée par une augmentation massive des transactions entrantes (6 millions par seconde) qui surchargeait le réseau, dépassant la capacité du réseau de 100 Gbit/s au niveau des nœuds individuels.

"Il n'y a aucune preuve d'une attaque par déni de service, mais des preuves indiquent que des robots ont tenté de gagner par programme un nouveau NFT créé à l'aide du programme populaire Candy Machine." les développeurs du projet ont déclaré dans le blog, « la cause première de l'utilisation élevée de la mémoire était l'insuffisance des votes pour finaliser les blocs précédents, empêchant ainsi le nettoyage des forks abandonnés. Le nombre de validateurs de forks devaient évaluer dépassait leur capacité à le faire, même après un redémarrage, nécessitant une intervention manuelle.

Que fait-on?

Selon l'équipe de développement, depuis début janvier, Solana a souffert de problèmes de congestion intermittents résultant de l'activité des robots ciblant les monnaies NFT. La précédente panne de Mainnet Beta s’est produite en septembre 2021 et a duré 17 heures. La panne du 30 avril partage les mêmes caractéristiques que celle de septembre, mais cette fois le réseau a continué à fonctionner même si les volumes de demandes de transactions ont atteint 10,000 XNUMX % du niveau de septembre, reflétant les mises à jour ultérieures effectuées par la communauté des validateurs.

La branche de la version bêta, v1.10, qui est actuellement en cours de stabilisation sur Testnet, inclut des améliorations de l'utilisation de la mémoire pour prolonger la durée pendant laquelle les nœuds peuvent supporter un consensus lent ou bloqué. Les nœuds de test exécutant la version 1.10 déployés sur Mainnet Beta se sont poursuivis pendant 2000 1.9 emplacements supplémentaires au-delà de leurs homologues vXNUMX aux spécifications similaires.

Trois mesures d'atténuation sont en cours pour garantir la stabilité et la résilience du réseau.

  • QUIC – Aujourd'hui, Solana utilise un protocole personnalisé basé sur UDP brut pour transmettre les transactions entre les nœuds RPC et le leader actuel. Étant donné qu'UDP est sans connexion et ne dispose pas à la fois de contrôle de flux et d'accusé de réception, il n'existe aucun moyen significatif de décourager ou d'atténuer les comportements abusifs. Afin d'affecter le contrôle du trafic réseau, les protocoles principaux de Solana sont réimplémentés sur QUIC, un protocole construit par Google, conçu pour une communication asynchrone rapide comme UDP, mais avec des sessions et un contrôle de flux comme TCP. Une fois adoptée, de nombreuses autres options seront disponibles pour adapter et optimiser l’ingestion de données.
  • QoS des transactions pondérées en fonction des enjeux – La bande passante du réseau Leader a une capacité fixe et pour l’utiliser efficacement, la priorisation est indispensable afin de mettre fin à la pratique actuelle consistant à accepter sans discernement les transactions sur la base du premier arrivé, premier servi, sans égard à la source. Étant donné que Solana est un réseau PoS, étendre l’utilité de la pondération des participations à la qualité de service des transactions est un choix naturel. Dans ce modèle, un nœud avec une participation de 0.5 % aura le droit de transmettre au moins 0.5 % des paquets au leader, et le reste du réseau et aucune combinaison de la participation restante ne pourra les éliminer complètement. La QoS pondérée par les enjeux est aujourd'hui en développement parallèle avec QUIC. La QoS pondérée en fonction des enjeux sera plus robuste en conjonction avec QUIC.
  • Priorité d’exécution basée sur les frais – Une fois ingérées, les transactions peuvent toujours être confrontées à la modification des données du compte partagé. Cette controverse a été résolue selon le simple principe du premier arrivé, premier servi, de la même manière que pour les ingestions de données réseau, ne laissant aux utilisateurs aucun moyen d'exprimer l'urgence de l'exécution de leurs transactions. Étant donné que n’importe qui peut soumettre des transactions au réseau, la pondération des enjeux n’est pas adaptée à cette priorisation. Au lieu de cela, une nouvelle instruction est introduite dans le programme Compute Budget, offrant aux utilisateurs la possibilité de spécifier des « frais supplémentaires » arbitraires à collecter lors de l'exécution de la transaction et de son inclusion dans un bloc. Le rapport entre ces frais et les unités de calcul demandées servira de poids de priorité d'exécution d'une transaction. Les frais supplémentaires seront traités de la même manière que les frais de base actuels.

La priorisation des frais est en cours et est ciblée pour la version v1.11.

AVIS DE NON-RESPONSABILITÉ : Les informations contenues sur ce site Web sont fournies à titre de commentaire général du marché et ne constituent pas un conseil en investissement. Nous vous encourageons à faire vos propres recherches avant d’investir.

Rejoignez CoinCu Telegram pour suivre l'actualité : https://t.me/coincunews

Suivez la chaîne Youtube CoinCu | Suivez la page Facebook de CoinCu

Hazel

Nouvelles CoinCu

solana solana solana

Connaissance, Blockchain

Qu'est-ce qui a causé la récente panne de Solana et que fait-on pour éviter une nouvelle congestion du réseau ?

solana

Quelle est la cause de la récente panne de Solana ?

Bots liés à un nouveau projet NFT basé sur Solana a entraîné une panne de réseau de sept heures, selon les développeurs du projet. La panne, qui a commencé vers 20h30 UTC samedi et s'est terminée dimanche à 03h30 UTC, a été causée par une augmentation massive des transactions entrantes (6 millions par seconde) qui surchargeait le réseau, dépassant la capacité du réseau de 100 Gbit/s au niveau des nœuds individuels.

"Il n'y a aucune preuve d'une attaque par déni de service, mais des preuves indiquent que des robots ont tenté de gagner par programme un nouveau NFT créé à l'aide du programme populaire Candy Machine." les développeurs du projet ont déclaré dans le blog, « la cause première de l'utilisation élevée de la mémoire était l'insuffisance des votes pour finaliser les blocs précédents, empêchant ainsi le nettoyage des forks abandonnés. Le nombre de validateurs de forks devaient évaluer dépassait leur capacité à le faire, même après un redémarrage, nécessitant une intervention manuelle.

Que fait-on?

Selon l'équipe de développement, depuis début janvier, Solana a souffert de problèmes de congestion intermittents résultant de l'activité des robots ciblant les monnaies NFT. La précédente panne de Mainnet Beta s’est produite en septembre 2021 et a duré 17 heures. La panne du 30 avril partage les mêmes caractéristiques que celle de septembre, mais cette fois le réseau a continué à fonctionner même si les volumes de demandes de transactions ont atteint 10,000 XNUMX % du niveau de septembre, reflétant les mises à jour ultérieures effectuées par la communauté des validateurs.

La branche de la version bêta, v1.10, qui est actuellement en cours de stabilisation sur Testnet, inclut des améliorations de l'utilisation de la mémoire pour prolonger la durée pendant laquelle les nœuds peuvent supporter un consensus lent ou bloqué. Les nœuds de test exécutant la version 1.10 déployés sur Mainnet Beta se sont poursuivis pendant 2000 1.9 emplacements supplémentaires au-delà de leurs homologues vXNUMX aux spécifications similaires.

Trois mesures d'atténuation sont en cours pour garantir la stabilité et la résilience du réseau.

  • QUIC – Aujourd'hui, Solana utilise un protocole personnalisé basé sur UDP brut pour transmettre les transactions entre les nœuds RPC et le leader actuel. Étant donné qu'UDP est sans connexion et ne dispose pas à la fois de contrôle de flux et d'accusé de réception, il n'existe aucun moyen significatif de décourager ou d'atténuer les comportements abusifs. Afin d'affecter le contrôle du trafic réseau, les protocoles principaux de Solana sont réimplémentés sur QUIC, un protocole construit par Google, conçu pour une communication asynchrone rapide comme UDP, mais avec des sessions et un contrôle de flux comme TCP. Une fois adoptée, de nombreuses autres options seront disponibles pour adapter et optimiser l’ingestion de données.
  • QoS des transactions pondérées en fonction des enjeux – La bande passante du réseau Leader a une capacité fixe et pour l’utiliser efficacement, la priorisation est indispensable afin de mettre fin à la pratique actuelle consistant à accepter sans discernement les transactions sur la base du premier arrivé, premier servi, sans égard à la source. Étant donné que Solana est un réseau PoS, étendre l’utilité de la pondération des participations à la qualité de service des transactions est un choix naturel. Dans ce modèle, un nœud avec une participation de 0.5 % aura le droit de transmettre au moins 0.5 % des paquets au leader, et le reste du réseau et aucune combinaison de la participation restante ne pourra les éliminer complètement. La QoS pondérée par les enjeux est aujourd'hui en développement parallèle avec QUIC. La QoS pondérée en fonction des enjeux sera plus robuste en conjonction avec QUIC.
  • Priorité d’exécution basée sur les frais – Une fois ingérées, les transactions peuvent toujours être confrontées à la modification des données du compte partagé. Cette controverse a été résolue selon le simple principe du premier arrivé, premier servi, de la même manière que pour les ingestions de données réseau, ne laissant aux utilisateurs aucun moyen d'exprimer l'urgence de l'exécution de leurs transactions. Étant donné que n’importe qui peut soumettre des transactions au réseau, la pondération des enjeux n’est pas adaptée à cette priorisation. Au lieu de cela, une nouvelle instruction est introduite dans le programme Compute Budget, offrant aux utilisateurs la possibilité de spécifier des « frais supplémentaires » arbitraires à collecter lors de l'exécution de la transaction et de son inclusion dans un bloc. Le rapport entre ces frais et les unités de calcul demandées servira de poids de priorité d'exécution d'une transaction. Les frais supplémentaires seront traités de la même manière que les frais de base actuels.

La priorisation des frais est en cours et est ciblée pour la version v1.11.

AVIS DE NON-RESPONSABILITÉ : Les informations contenues sur ce site Web sont fournies à titre de commentaire général du marché et ne constituent pas un conseil en investissement. Nous vous encourageons à faire vos propres recherches avant d’investir.

Rejoignez CoinCu Telegram pour suivre l'actualité : https://t.me/coincunews

Suivez la chaîne Youtube CoinCu | Suivez la page Facebook de CoinCu

Hazel

Nouvelles CoinCu

solana solana solana

Visité 94 fois, 1 visite(s) aujourd'hui