Modularne blockchainy: prześledź wykonanie, dane i rozliczenie

Modularny łańcuch bloków dzieli obowiązki między komponenty, zamiast wymagać od jednego systemu wykonania każdego zadania. To może sprawiać, że opis sieci wydaje się prosty: wykonanie odbywa się tutaj, dane trafiają tam, a rozliczanie odbywa się gdzie indziej. Ważnym pytaniem jest to, co faktycznie gwarantuje każdy komponent.

W artykule porównano role architektoniczne, a nie symboliczne ceny czy ranking projektów. Konstrukcja modułowa nie oznacza automatycznie niższego ryzyka, wyższych zwrotów z inwestycji lub identycznego bezpieczeństwa we wszystkich wdrożeniach.

Oddziel zadania przed porównaniem systemów

Wykonanie stosuje reguły transakcji i oblicza proponowaną zmianę stanu. Dostępność danych dotyczy tego, czy udostępniono informacje potrzebne do weryfikacji systemu. Rozliczenie dotyczy sposobu akceptowania kryptograficznych zobowiązań dotyczących stanu łańcucha (state commitments), dowodów lub sporów w ramach konkretnego protokołu. Konsensus określa uzgodnioną kolejność lub zaakceptowaną historię w systemie.

Role te mogą się pokrywać lub być rozdzielane na różne sposoby. Etykiety projektu nie wystarczą: sieć może nazwać siebie modułową, zachowując jednocześnie znaczną kontrolę nad sekwencerem, kluczem aktualizacji lub komisją danych. Zamiast zakładać, że wszystkie sieci modułowe korzystają z jednego modelu zaufania, narysuj rzeczywistą mapę zależności.

Dokumentacja dostępności danych Ethereum wyjaśnia, dlaczego weryfikacja zależy od dostępu do danych transakcyjnych i dlaczego lżejsi klienci i rollupy wymagają odpowiednich zabezpieczeń. Dostęp do danych to inna kwestia niż poprawność wykonanych obliczeń.

Wykonaj hipotetyczną transakcję

Wyobraź sobie, że użytkownik wysyła transakcję do sieci wykonawczej. Sekwencer włącza go do partii. System udostępnia wymagane dane w wybranej przez siebie warstwie danych oraz przekazuje kryptograficzne zobowiązanie dotyczące stanu łańcucha (state commitment), wraz z wymaganym przez jego konstrukcję mechanizmem weryfikacji, do warstwy rozliczeniowej.

Użytkownik może zobaczyć wcześniejsze potwierdzenie, zanim każdy etap osiągnie swój ostateczny status. Zapisz, co oznacza każdy status: otrzymano, uporządkowano, wykonano, dane opublikowano, dowód zaakceptowano lub ukończono okno sporu. Nie oznaczaj najwcześniejszego potwierdzenia jako ostatecznego rozliczenia, chyba że protokół potwierdza taką interpretację.

Ten przykład opisuje role, a nie przepisuje jedną uniwersalną sekwencję. Różne rollupy i systemy modułowe mogą łączyć etapy lub wykorzystywać różne rozwiązania sprawdzające i finalne.

Zapytaj, co się stanie, gdy komponent ulegnie awarii

Jeśli sekwencer się zatrzyma, czy użytkownicy mogą przesyłać transakcje w inny sposób i pod jakimi warunkami? Jeśli usługa danych zataja informacje, kto je wykrywa i co użytkownicy mogą zweryfikować? Jeśli warstwa rozliczeniowa jest przeciążona, jak wpływa to na zobowiązania lub wypłaty?

Odpowiedz na te pytania na podstawie aktualnej dokumentacji, w tym procedur awaryjnych i kontroli administracyjnych. Rozwiązanie awaryjne opisane w planie działania niekoniecznie jest funkcjonalne. Sieć, która w dalszym ciągu wyświetla salda, może nadal mieć ograniczoną zdolność akceptowania transakcji lub dokonywania wypłat.

Przejrzyj oddzielnie zależności mostu. Token pojawiający się w dwóch sieciach nie oznacza, że trasa transferu dziedziczy wszystkie właściwości bezpieczeństwa obu łańcuchów.

Porównaj całkowity koszt i wygodę użytkownika

Niska opłata za realizację to tylko część kosztów transakcji. Publikacja danych, operacje rozliczeniowe, pomostowe i wycofania mogą powodować dodatkowe opłaty lub opóźnienia. Porównaj równoważne działania w tym samym okresie i wyjaśnij, kto płaci jakie koszty.

Zmierz pełną trasę istotną dla użytkownika: wejście, wykonanie, potwierdzenie, wycofanie i powrót do żądanego zasobu lub sieci. Benchmarku obejmującego tylko jeden etap nie należy podawać jako ceny całego przejazdu w obie strony. Oszczędności mogą się także różnić w zależności od zapotrzebowania i warunków warstwy danych.

Użyj listy kontrolnej zależności

Dla każdego systemu należy zapisać zasady realizacji, organ zamawiający, lokalizację danych, mechanizm weryfikacji, miejsce docelowe rozliczenia, kontrolę aktualizacji i procedurę wyjścia. Zaznacz, które roszczenia są aktywne, a które są planowane. Podaj źródła i zaznaczoną datę, ponieważ ustawienia architektoniczne mogą ulec zmianie.

W przypadku pokrewnego, ale odrębnego problemu przeczytaj porównanie wiadomości między łańcuchami: przestrzega instrukcji między łańcuchami, podczas gdy ten przewodnik opisuje podział pracy wewnątrz architektury.

Projekt techniczny protokołu i prawa ekonomiczne jego tokena to odrębne pytania badawcze. Sprawdź niezależnie użyteczność tokena i rzeczywistą dostępność na rynku za pomocą oficjalnej dokumentacji i strony OrangeX Markets, zamiast traktować roszczenie dotyczące skalowania jako wniosek handlowy.