AWS a subi une panne à l'échelle de la région. Des dizaines de milliers d'applications - Venmo, Reddit, Zoom, Roblox, même les propres services d'Amazon ont été mis hors ligne. Mais quelques-uns n'ont pas été affectés car ils fonctionnaient sur @WalrusProtocol, via @SuiNetwork. Décomposons pourquoi [Research series]↓

La panne d'AWS a été retracée à US-EAST-1, la région qui alimente discrètement la moitié d'Internet. Lorsque cela a échoué, les couches DNS et API se sont effondrées, créant une cascade de temps d'arrêt. Même les applications avec des "sauvegardes" sont devenues inaccessibles car leurs sauvegardes se trouvaient dans la même région.

Que révèle la gigantesque panne d'AWS sur Internet ? Qu'un seul échec en Virginie ne devrait pas faire taire une planète, et pourtant c'est ce qui s'est passé. Et nous avons construit un web mondial sur une colonne vertébrale locale et confondu taille avec stabilité.

Mais cet échec n'était pas nouveau. C'est le même schéma à chaque fois : centralisation + commodité → fragilité. Un fournisseur, une région, une API. Tout ce qu'il faut, c'est un seul point de congestion pour que le web clignote.

Pourquoi est-ce important ? Dans AWS ou Google Cloud : - Vous faites confiance à leur tableau de bord lorsqu'il indique "stocké avec succès". - Si leur région échoue, vous ne pouvez pas prouver de manière indépendante quelles données existent encore. Dans Walrus : - La preuve est publique et décentralisée. - Même si certains nœuds échouent, le reçu vous permet de confirmer quels fragments restent et où. Walrus remplace la confiance par la vérification.

Une autre différence : - AWS suppose un temps de disponibilité : Il est conçu pour l'efficacité et l'échelle, s'attendant à ce que les pannes soient des exceptions rares qui peuvent être corrigées ou redirigées. - @WalrusProtocol suppose l'échec : Il est construit sous l'attente que des nœuds échoueront - donc la survie du système ne dépend d'aucun nœud, région ou fournisseur unique.

Walrus est ce que nous appelons un design antifragile : un système qui ne se casse pas lorsque certaines de ses parties le font. Et c'est pourquoi, lors d'une panne d'AWS, les applications basées sur Walrus ont continué à fonctionner - non pas parce qu'elles ont de la chance, mais parce que le système ne dépend d'aucune pièce unique pour survivre.

Survivre à l'échec est la moitié de l'histoire. L'autre moitié consiste à savoir et à montrer que vos données n'ont jamais disparu en premier lieu. Parce que Walrus est une continuité vérifiable, l'opposé de "croyez-nous sur parole". Vous pouvez prouver non seulement que vous avez stocké des données, mais aussi où elles se trouvent, comment elles sont répliquées et qu'elles restent récupérables. C'est quelque chose qu'aucun fournisseur lié à une région ne peut promettre.

L'événement AWS a réaffirmé une vérité plus grande : La décentralisation n'est plus une question d'idéologie ; c'est une question de survie. Les systèmes centralisés échouent ensemble. Les systèmes distribués se dégradent gracieusement car l'échec est asynchrone. Si un nœud, une zone ou un cluster échoue, le reste continue de fonctionner. La performance peut légèrement diminuer, mais le système ne s'effondre pas et ne meurt pas.

La panne d'AWS a rendu une chose claire : le "cloud" n'est pas le ciel, c'est le centre de données de quelqu'un d'autre en Virginie. Walrus étend ce ciel à travers le monde ; vérifiable, sans autorisation, récupérable. Lorsque le web est devenu noir, Walrus n'a pas cligné des yeux car la résilience était le principe.