Obserwacja zatorów w sieci
Czasami obserwuję, jak inne łańcuchy się zacinają. Opłaty rosną, a wszystko zwalnia. Moje obserwacje dotyczące @Plasma są inne. Projekt radzi sobie z obciążeniem, nie obsługując go na głównym łańcuchu. Każda aplikacja ma swoją przestrzeń. Swój własny łańcuch podrzędny.
Zatory w jednym ekosystemie pozostają tam. Nie przelewają się. Nie mogą obciążyć całej sieci. To jest fakt strukturalny, a nie obietnica.
Doświadczenie użytkownika jest izolowane. Jeśli łańcuch gier jest zajęty, moja aktywność na łańcuchu społecznościowym nie jest dotknięta. Działają osobno. Rozliczają się z głównym łańcuchem niezależnie. Ta compartmentalizacja jest logiczna.
Myślę o mechanizmie wyjścia tutaj. Ma to znaczenie podczas wysokiego obciążenia. Użytkownicy mają bezpośrednią ścieżkę do głównego łańcucha. To prawo jest wbudowane. To nie jest myśl dodatkowa. Stres sieciowy na łańcuchu podrzędnym nie usuwa tej opcji. To jest ważny punkt projektowy.
System nie zapobiega zatorom. Lokalizuje je. To pozwala na dostosowane rozwiązania. Społeczność może zarządzać swoją własną przestrzenią blokową. Może dostosować swoje własne zasady do swoich potrzeb. Bezpieczeństwo warstwy podstawowej pozostaje niezmienione.
To podejście tworzy inny rodzaj skalowania. Nie chodzi o to, aby jeden łańcuch działał szybciej. Chodzi o wiele łańcuchów działających bez narzucania kosztów na siebie nawzajem. Obciążenie jest rozłożone zgodnie z projektem.
Postrzegam to jako długoterminową korzyść architektoniczną. Unika problemu pojedynczego rurociągu. Aktywność rośnie w jednym obszarze. Inne obszary nie są karane. Sieć wydaje się cichsza, nawet gdy niektóre jej części są bardzo zajęte.
