Większość ludzi patrzy na Terra Classic i widzi blockchain. Widzą walidatorów, staking, propozycje zarządzania, transfery tokenów i silnik konsensusu działający pod tym wszystkim. To zrozumiałe. Blockchain to widoczna część systemu. To także najłatwiejsza część do omówienia.
Trudniejsza rozmowa zaczyna się, gdy śledzisz, co tak naprawdę dzieje się po tym, jak użytkownik otworzy portfel, sprawdzi saldo, poszuka transakcji, monitoruje nagrody ze stakingu lub oczekuje, że transfer pojawi się natychmiast na ekranie. W tym momencie nie mówisz już o blockchainie. Mówisz o rozproszonym systemie z dziesiątkami ruchomych części, z których każda jest zoptymalizowana do innej pracy, a każda wprowadza swoje własne tryby awarii.
Branża uwielbia przedstawiać czystą historię. Użytkownik składa transakcję. Walidatorzy ją przetwarzają. Osiągnięto konsensus. Stan się aktualizuje. Koniec.
Rzeczywistość jest znacznie bardziej chaotyczna.
Terra Classic działa na Tendermint, a jednym z powodów, dla których Tendermint stał się tak szeroko adoptowany, jest to, że dobrze oddziela różne aspekty. Konsensus i sieciowanie żyją w jednej warstwie, podczas gdy logika aplikacji znajduje się gdzie indziej. To brzmi prosto, dopóki nie zdasz sobie sprawy, jak dużo złożoności jest wpychane w wszystko, co otacza łańcuch. Konsensus może określać, co jest prawdą, ale większość interakcji użytkowników ma niewiele wspólnego z samym konsensusem. Użytkownicy chcą informacji. Chcą ich od razu. Chcą, aby były dostarczane przez interfejsy, które wydają się responsywne, nawet gdy podległa sieć robi coś znacznie wolniejszego i bardziej skomplikowanego.
Ten popyt tworzy całkowicie inne wyzwanie architektoniczne.
Węzeł walidatora jest w pełni zdolny do przechowywania stanu blockchaina. Co nie jest jego mocną stroną, to obsługiwanie tysięcy wysoce specyficznych zapytań aplikacyjnych co sekundę. Poproś eksploratora blockchaina, aby przeszukał lata historii transakcji, zsumował metryki walidatorów, obliczył nagrody za staking i filtrował aktywność na wielu kontach, a nagle łańcuch staje się niezręcznym miejscem do wykonywania tych operacji.
Więc pojawiają się dodatkowe warstwy.
Każdy dojrzały ekosystem blockchaina ostatecznie buduje równoległą infrastrukturę danych. Surowe zdarzenia blockchaina są przesyłane do baz danych relacyjnych, gdzie dane mogą być indeksowane, normalizowane i zapytane efektywnie. PostgreSQL wykonuje pracę, do której blockchainy nigdy nie były zaprojektowane. Nie dlatego, że technologia blockchaina zawiodła, ale dlatego, że różne narzędzia istnieją dla różnych zadań.
Wzorzec powtarza się wszędzie.
Nowy blok zostaje zfinalizowany. Zdarzenia są emitowane. Indeksatory konsumują te zdarzenia. Bazy danych aktualizują rekordy. Systemy analityczne odświeżają pulpity. Systemy monitorujące generują alerty. API eksponują wynikowy stan aplikacjom. To, co użytkownicy postrzegają jako "blockchain", jest często wynikiem architektury opartej na zdarzeniach działającej wokół blockchaina, a nie wewnątrz niego.
To rozróżnienie staje się boleśnie oczywiste w okresach dużego obciążenia.
Widziałem systemy, w których konsensus działał normalnie, podczas gdy użytkownicy zalewali kanały wsparcia, twierdząc, że sieć jest wyłączona. Blockchain nie był wyłączony. Pipeline indeksowania był opóźniony. Przeciążony klaster API przekraczał czas oczekiwania. Proces unieważnienia pamięci podręcznej pozostawał w tyle. Z perspektywy użytkownika różnica była nieistotna. Ich portfel wyglądał na zepsuty.
To niewygodna rzeczywistość nowoczesnej infrastruktury Web3. Dostępność nie jest już określana wyłącznie przez czas pracy walidatorów. Otaczający ekosystem ma równie duże znaczenie.
Wydajność tworzy jeszcze jedną warstwę złożoności, która rzadko jest omawiana szczerze.
Każdy chce responsywności w czasie rzeczywistym. Nikt nie chce czekać kilku sekund na odświeżenie sald lub załadowanie historii transakcji. Rozwiązanie wydaje się proste, dopóki nie zaczniesz obsługiwać systemów na dużą skalę. Powtarzające się zapytania do baz danych głównych stają się kosztowne. Bezpośrednie pobieranie informacji z węzłów blockchaina staje się nieefektywne. Latencja zaczyna wzrastać. Koszty infrastruktury zaczynają rosnąć.
Wtedy do gry wchodzi Redis.
Pamięć podręczna wydaje się niemal magiczna, gdy działa. Często żądane dane przechodzą do pamięci, gdzie pobieranie odbywa się w mikrosekundach, a nie milisekundach. Czas odpowiedzi API się skraca. Interfejsy użytkownika wydają się natychmiastowe. Koszty operacyjne poprawiają się.
Potem ktoś musi utrzymać spójność.
Nagle pojawia się inny zestaw pytań. Co się dzieje, gdy stan w pamięci podręcznej różni się od stanu blockchaina? Jak agresywnie powinno następować unieważnienie? Ile tymczasowej niespójności jest akceptowalne? W którym momencie poprawa responsywności zaczyna podważać dokładność?
Każdy zespół inżynieryjny ostatecznie odkrywa tę samą prawdę: wydajność zazwyczaj jest kupowana za cenę złożoności.
Nie ma na to skrótu.
W momencie, gdy system staje się szybki, ktoś gdzieś zarządza problemami synchronizacji za kulisami.
Ta sama napięcie istnieje między tym, co widzą użytkownicy, a tym, co blockchain faktycznie zfinalizował. Wiele nowoczesnych aplikacji polega na interfejsach predykcyjnych, ponieważ czekanie na pełne uregulowanie często wydaje się wolne. Portfel może optymistycznie wyświetlać transakcję, zanim wszystkie wspierające usługi w pełni się zsynchronizują. Eksplorator może ujawniać aktywność, zanim każdy system downstream przetworzy strumień zdarzeń. Użytkownicy interpretują to jako prędkość. Inżynierowie dostrzegają to jako starannie zarządzane postrzeganie.
Ani jedna, ani druga perspektywa nie są błędne.
Jedno koncentruje się na doświadczeniu. Drugie koncentruje się na spójności stanu.
Utrzymanie tych dwóch rzeczywistości w zgodzie staje się coraz trudniejsze, gdy ekosystemy rosną.
Dlatego też trwająca debata między wykonaniem on-chain a off-chain często pomija sedno sprawy. Rozmowa jest często przedstawiana jako ideologiczna, gdy w rzeczywistości jest to kwestia architektoniczna.
Niektóre funkcje należą do on-chain, ponieważ minimalizacja zaufania ma znaczenie. Własność tokenów, stan stakingu, wyniki zarządzania, uczestnictwo walidatorów i zasady konsensusu potrzebują gwarancji kryptograficznych. To kosztowne operacje, ale uzasadniają koszty, ponieważ integralność jest nienażalna.
Inne obciążenia mają zupełnie inne wymagania.
Systemy wyszukiwania potrzebują elastyczności. Platformy analityczne potrzebują agregacji. Silniki powiadomień potrzebują responsywności. Pulpity portfela potrzebują szybkiego pobierania. Zmuszenie każdej z tych usług do pracy w środowisku blockchaina stworzyłoby wolniejszy, droższy i znacznie bardziej złożony system.
Hybrdowe architektury nie są kompromisem. To konieczność.
Branża często traktuje infrastrukturę off-chain, jakby była w jakiś sposób mniej ważna niż sam łańcuch. Operacyjnie, przeciwnie, jest często prawdą. Większość incydentów produkcyjnych nie pochodzi z awarii konsensusu. Pochodzą z przeciążonych baz danych, wyczerpanych pul połączeń, opóźnionych konsumentów zdarzeń, problemów z synchronizacją pamięci podręcznej, wąskich gardeł RPC, czy API, które są bombardowane ruchem, do którego nie były zaprojektowane.
Łańcuch nadal produkuje bloki.
Wszystko wokół zaczyna mieć problemy.
Długoterminowa skalowalność staje się interesująca, gdy patrzy się na to przez ten pryzmat. Ludzie naturalnie zakładają, że skalowanie blockchaina dotyczy przezroczystości transakcji. Przezroczystość ma znaczenie, ale nie zawsze jest pierwszym wąskim gardłem, które się pojawia. Więcej użytkowników generuje więcej zapytań. Więcej zapytań generuje więcej zindeksowanych danych. Więcej zindeksowanych danych zwiększa wymagania dotyczące przechowywania. Więcej przechowywania generuje więcej kosztów replikacji. Więcej usług tworzy więcej zależności. Więcej zależności tworzy więcej złożoności operacyjnej.
Wzrost kumuluje się w kierunkach, które rzadko są omawiane w białych księgach.
Blockchain może nadal efektywnie przetwarzać transakcje, podczas gdy wspierająca infrastruktura absorbuje exponentially rosnące obciążenie.
Dlatego architektura Terra Classic opowiada większą historię, niż większość ludzi zdaje sobie sprawę. Pod siecią walidatorów znajduje się cały ekosystem baz danych, strumieni zdarzeń, pamięci podręcznych, interfejsów API, systemów monitorowania, usług synchronizacji i narzędzi operacyjnych, które stale pracują, aby przetłumaczyć stan blockchaina na coś, co ludzie mogą faktycznie wykorzystać.
Blockchain pozostaje źródłem prawdy. Wszystko inne istnieje, aby uczynić tę prawdę dostępną na dużą skalę.
I może to jest największe nieporozumienie dotyczące architektury blockchaina dzisiaj. Wyzwanie nie polega na zbudowaniu łańcucha, który osiąga konsensus. Tendermint rozwiązał dużą część tego problemu lata temu. Prawdziwe wyzwanie zaczyna się później. To zarządzanie rozległym rozproszonym systemem, który rośnie wokół udanych blockchainów, utrzymując każdą warstwę zsynchronizowaną, responsywną i niezawodną, podczas gdy ruch rośnie, dane się kumulują, a użytkownicy nadal oczekują, że wszystko będzie działać natychmiast.
To nie jest problem blockchaina.
To problem systemów rozproszonych. A te zazwyczaj są znacznie trudniejsze, niż wyglądają z zewnątrz.