Premier blocage de Sui après le lancement: les développeurs ont déclaré que cela ne posait pas de problème, et le lendemain, Franklin Templeton a annoncé une relation de coopération.
Récemment, le réseau public SUI a également été confronté à une situation embarrassante de blocage temporaire. Après deux heures et demie de blocage, l'équipe officielle de SUI a publié un rapport sur l'incident. Cependant, le blocage temporaire subi par SUI, qui se concentre sur la haute performance du réseau public, rappelle également le cas de Solana il y a quelques années. Bien que les deux aient des langages de programmation et des architectures très différents, tous deux se concentrent sur les réseaux publics à haute performance, mais sont également critiqués pour ne pas être assez décentralisés, etc.
Pourquoi un code de contrôle de congestion a-t-il entraîné l'effondrement de tous les validateurs?
Le rapport indique qu'aux premières heures du 21 novembre 2024, le Mainnet SUI a connu une panne complète, de 1h15 à 3h45, heure du Pacifique. Tous les validateurs sont tombés dans une boucle de crash, entraînant l'incapacité du réseau entier à traiter toute transaction. Cet événement met en évidence la nécessité de suivre étroitement la stabilité tout en améliorant les performances des chaînes publiques à haute performance.
Selon la déclaration officielle, la raison de cette suspension est qu'un segment de code 'assert!' dans le contrôle de congestion du réseau SUI a provoqué un effondrement des validateurs. Plus précisément, lorsque les conditions suivantes sont remplies simultanément, cela entraîne un effondrement du réseau :
Activation du mode TotalGasBudgetWithCap de contrôle des embouteillages.
Transaction received with the following characteristics: a mutable shared object as input, without any MoveCall instruction
Lorsque de telles transactions entrent dans le réseau, tous les validateurs s'effondrent simultanément, ce qui entraîne un arrêt du réseau.
Qu'est-ce que la gestion de la congestion?
L'architecture orientée objet de SUI Mainnet permet un traitement simultané de nombreuses transactions, ce qui lui permet d'atteindre des performances élevées. Cependant, si plusieurs transactions doivent être écrites dans le même objet partagé, elles doivent encore être exécutées séquentiellement, et la vitesse de traitement de ce type de transactions est limitée. Pour éviter les congestions causées par les objets partagés, SUI introduit un mécanisme de contrôle de congestion pour limiter la vitesse de transaction d'un objet partagé individuel. Note de l'auteur : lors d'une réunion de lecture hors ligne en collaboration avec XueDAO, la Fondation SUI a mentionné que sa logique consiste à regrouper et exécuter simultanément les transactions ayant une relation de cause à effet.
Récemment, SUI a mis à niveau son système de contrôle de la congestion, en introduisant le mode TotalGasBudgetWithCap pour évaluer plus précisément la complexité des transactions. Cependant, un défaut dans le code de ce mode a conduit à l'incident actuel. L'équipe SUI a rapidement réagi à la découverte du problème et a publié les mises à jour Mainnet v1.37.4 et Testnet v1.38.1 pour corriger le code (PR #20365). La communauté des validateurs a montré une efficacité de réponse extrêmement élevée, le temps entre la publication de la correction et la reprise du réseau n'ayant été que de 15 minutes.
Type de protocole : l'arrêt de la mise en bloc de SUI est complètement différent de Solana
L'arrêt des blocs Sui rappelle inévitablement Solana et même TON cette année. À ce sujet, Kyrie, le CGO du protocole Typus de la finance décentralisée sur Sui, a partagé sur Twitter l'avis des membres de l'équipe. Il a clairement indiqué que c'est totalement différent de l'arrêt des blocs sur Solana. Le problème de Solana est un effondrement du système causé par la congestion du réseau, nécessitant des améliorations architecturales à grande échelle pour être résolu, ce qui signifie également que le problème de Solana est difficile à résoudre à court terme. En revanche, l'incident de Sui est clairement un problème technique qui n'affecte pas l'infrastructure système.
Kyrie stated that the crash issue was caused by an overflow in calculating the Coût de transaction. In simple terms, it's like when the display on a calculator doesn't have enough digits and resets to zero when the number is too large. The system gets stuck in an infinite loop in this situation, ultimately leading to a network shutdown.
Lorsque la valeur calculée par le système dépasse la plage de stockage, la conception d'origine était de provoquer une erreur de calcul lorsqu'elle dépasse la plage, ce qui entraîne une répétition continue du système. Après la correction PR #20365, une limite de calcul correcte a été fixée pour éviter ce genre de situation. Il a également souligné que la clé de cet incident réside dans la logique de calcul du Coût de transaction, et non dans le Mécanisme de consensus SUI ou la conception du système. Cela explique également pourquoi la réparation a pu être effectuée rapidement et directement.
Franklin Templeton et SUI ont annoncé un partenariat
Juste avant la date limite de soumission, une nouvelle est arrivée : le lendemain de l'arrêt du blocage, la Fondation Sui a annoncé sa collaboration avec Franklin Templeton. Dans sa déclaration, Franklin Templeton a mentionné les protocoles et infrastructures suivants : Deepbook, Karrier One et ika. Cependant, compte tenu des opérations de Franklin Templeton sur la blockchain, on peut peut-être s'attendre à une combinaison de la chaîne publique Sui, axée sur la sécurité et orientée objet, avec les RWA.
Ce SUI premier blocage après le lancement de l'article sur SUI: les développeurs disent que ce n'est pas un gros problème, et le lendemain, Franklin Templeton a annoncé une relation de collaboration. Ça a été publié pour la première fois dans les nouvelles de la chaîne ABMedia.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Premier blocage de Sui après le lancement: les développeurs ont déclaré que cela ne posait pas de problème, et le lendemain, Franklin Templeton a annoncé une relation de coopération.
Récemment, le réseau public SUI a également été confronté à une situation embarrassante de blocage temporaire. Après deux heures et demie de blocage, l'équipe officielle de SUI a publié un rapport sur l'incident. Cependant, le blocage temporaire subi par SUI, qui se concentre sur la haute performance du réseau public, rappelle également le cas de Solana il y a quelques années. Bien que les deux aient des langages de programmation et des architectures très différents, tous deux se concentrent sur les réseaux publics à haute performance, mais sont également critiqués pour ne pas être assez décentralisés, etc.
Pourquoi un code de contrôle de congestion a-t-il entraîné l'effondrement de tous les validateurs?
Le rapport indique qu'aux premières heures du 21 novembre 2024, le Mainnet SUI a connu une panne complète, de 1h15 à 3h45, heure du Pacifique. Tous les validateurs sont tombés dans une boucle de crash, entraînant l'incapacité du réseau entier à traiter toute transaction. Cet événement met en évidence la nécessité de suivre étroitement la stabilité tout en améliorant les performances des chaînes publiques à haute performance.
Selon la déclaration officielle, la raison de cette suspension est qu'un segment de code 'assert!' dans le contrôle de congestion du réseau SUI a provoqué un effondrement des validateurs. Plus précisément, lorsque les conditions suivantes sont remplies simultanément, cela entraîne un effondrement du réseau :
Activation du mode TotalGasBudgetWithCap de contrôle des embouteillages.
Transaction received with the following characteristics: a mutable shared object as input, without any MoveCall instruction
Lorsque de telles transactions entrent dans le réseau, tous les validateurs s'effondrent simultanément, ce qui entraîne un arrêt du réseau.
Qu'est-ce que la gestion de la congestion?
L'architecture orientée objet de SUI Mainnet permet un traitement simultané de nombreuses transactions, ce qui lui permet d'atteindre des performances élevées. Cependant, si plusieurs transactions doivent être écrites dans le même objet partagé, elles doivent encore être exécutées séquentiellement, et la vitesse de traitement de ce type de transactions est limitée. Pour éviter les congestions causées par les objets partagés, SUI introduit un mécanisme de contrôle de congestion pour limiter la vitesse de transaction d'un objet partagé individuel. Note de l'auteur : lors d'une réunion de lecture hors ligne en collaboration avec XueDAO, la Fondation SUI a mentionné que sa logique consiste à regrouper et exécuter simultanément les transactions ayant une relation de cause à effet.
Récemment, SUI a mis à niveau son système de contrôle de la congestion, en introduisant le mode TotalGasBudgetWithCap pour évaluer plus précisément la complexité des transactions. Cependant, un défaut dans le code de ce mode a conduit à l'incident actuel. L'équipe SUI a rapidement réagi à la découverte du problème et a publié les mises à jour Mainnet v1.37.4 et Testnet v1.38.1 pour corriger le code (PR #20365). La communauté des validateurs a montré une efficacité de réponse extrêmement élevée, le temps entre la publication de la correction et la reprise du réseau n'ayant été que de 15 minutes.
Type de protocole : l'arrêt de la mise en bloc de SUI est complètement différent de Solana
L'arrêt des blocs Sui rappelle inévitablement Solana et même TON cette année. À ce sujet, Kyrie, le CGO du protocole Typus de la finance décentralisée sur Sui, a partagé sur Twitter l'avis des membres de l'équipe. Il a clairement indiqué que c'est totalement différent de l'arrêt des blocs sur Solana. Le problème de Solana est un effondrement du système causé par la congestion du réseau, nécessitant des améliorations architecturales à grande échelle pour être résolu, ce qui signifie également que le problème de Solana est difficile à résoudre à court terme. En revanche, l'incident de Sui est clairement un problème technique qui n'affecte pas l'infrastructure système.
Kyrie stated that the crash issue was caused by an overflow in calculating the Coût de transaction. In simple terms, it's like when the display on a calculator doesn't have enough digits and resets to zero when the number is too large. The system gets stuck in an infinite loop in this situation, ultimately leading to a network shutdown.
Lorsque la valeur calculée par le système dépasse la plage de stockage, la conception d'origine était de provoquer une erreur de calcul lorsqu'elle dépasse la plage, ce qui entraîne une répétition continue du système. Après la correction PR #20365, une limite de calcul correcte a été fixée pour éviter ce genre de situation. Il a également souligné que la clé de cet incident réside dans la logique de calcul du Coût de transaction, et non dans le Mécanisme de consensus SUI ou la conception du système. Cela explique également pourquoi la réparation a pu être effectuée rapidement et directement.
Franklin Templeton et SUI ont annoncé un partenariat
Juste avant la date limite de soumission, une nouvelle est arrivée : le lendemain de l'arrêt du blocage, la Fondation Sui a annoncé sa collaboration avec Franklin Templeton. Dans sa déclaration, Franklin Templeton a mentionné les protocoles et infrastructures suivants : Deepbook, Karrier One et ika. Cependant, compte tenu des opérations de Franklin Templeton sur la blockchain, on peut peut-être s'attendre à une combinaison de la chaîne publique Sui, axée sur la sécurité et orientée objet, avec les RWA.
Ce SUI premier blocage après le lancement de l'article sur SUI: les développeurs disent que ce n'est pas un gros problème, et le lendemain, Franklin Templeton a annoncé une relation de collaboration. Ça a été publié pour la première fois dans les nouvelles de la chaîne ABMedia.