Autor: Kernel Ventures Jerry Luo

Recenzenci: Kernel Ventures Mandy, Kernel Ventures Joshua

TDR:

  1. Wczesne łańcuchy publiczne wymagały od wszystkich węzłów sieci utrzymywania spójności danych w celu zapewnienia bezpieczeństwa i decentralizacji. Jednak wraz z rozwojem ekosystemu blockchain obciążenie magazynowaniem stale rośnie, co prowadzi do trendu scentralizowanego działania węzłów. Na tym etapie warstwa 1 musi pilnie rozwiązać problem kosztów przechowywania spowodowany rozwojem TPS.

  2. W obliczu tego problemu programiści muszą zaproponować nowe rozwiązania w zakresie przechowywania danych historycznych, biorąc pod uwagę bezpieczeństwo, koszt przechowywania, szybkość odczytu danych i wszechstronność warstwy DA.

  3. W procesie rozwiązywania tego problemu pojawiło się wiele nowych technologii i pomysłów, w tym Sharding, DAS, Verkle Tree, pośrednie komponenty DA itp. Próbowali zoptymalizować rozwiązanie pamięci masowej warstwy DA, zmniejszając redundancję danych i zwiększając wydajność weryfikacji danych.

  4. Obecne rozwiązania DA można podzielić na dwie kategorie, w zależności od miejsca przechowywania danych, a mianowicie DA głównego łańcucha i DA stron trzecich. Główny łańcuch DA rozpoczyna się od perspektywy regularnego czyszczenia danych i partycjonowania danych w celu zmniejszenia obciążenia pamięci masowej węzłów. Wymagania projektowe zewnętrznych administratorów danych mają na celu świadczenie usług przechowywania danych i oferowanie rozsądnych rozwiązań dla dużych ilości danych. W związku z tym najważniejszym kompromisem jest kompatybilność pojedynczego łańcucha i kompatybilność wielu łańcuchów, a zaproponowano trzy rozwiązania: dedykowany DA łańcucha głównego, modułowy DA i publiczny DA łańcucha pamięci masowej.

  5. Publiczne łańcuchy płatności mają wyjątkowo wysokie wymagania dotyczące bezpieczeństwa danych historycznych i nadają się do stosowania łańcucha głównego jako warstwy DA. Jednak w przypadku publicznych łańcuchów, które działają od dłuższego czasu i w których sieć obsługuje duża liczba górników, bardziej odpowiednie byłoby zastosowanie zewnętrznego DA, który nie obejmuje warstwy konsensusu i bierze pod uwagę kwestie bezpieczeństwa. Kompleksowe łańcuchy publiczne lepiej nadają się do korzystania z pamięci masowej DA specyficznej dla łańcucha głównego, charakteryzującej się większą pojemnością danych, niższymi kosztami i bezpieczeństwem. Biorąc jednak pod uwagę wymagania międzyłańcuchowe, modułowe DA jest również dobrym rozwiązaniem.

  6. Ogólnie rzecz biorąc, technologia blockchain zmierza w kierunku ograniczania redundancji danych i podziału pracy między wiele łańcuchów.

1. Tło

Jako rozproszony rejestr, blockchain musi przechowywać kopię historycznych danych na wszystkich węzłach, aby zagwarantować bezpieczeństwo i wystarczającą decentralizację przechowywania danych. Ponieważ poprawność każdej zmiany stanu jest związana z poprzednim stanem (źródłem transakcji), w celu zapewnienia poprawności transakcji blockchain powinien zasadniczo przechowywać wszystkie historyczne zapisy od pierwszej do bieżącej transakcji. Biorąc za przykład Ethereum, nawet jeśli średni rozmiar każdego bloku oszacujemy na 20 kb, obecny całkowity rozmiar bloków Ethereum osiągnął 370 GB. Oprócz samego bloku, pełny węzeł musi także rejestrować status i potwierdzenia transakcji. Łącznie z tą częścią, całkowita pamięć pojedynczego węzła przekroczyła 1 TB, co sprawia, że ​​obsługa węzła jest skoncentrowana w rękach kilku osób.

Najnowsza wysokość bloku Ethereum, źródło obrazu: Etherscan

Ostatnia aktualizacja Ethereum Cancun ma na celu zwiększenie TPS Ethereum do około 1000, w którym to czasie roczny wzrost pamięci masowej Ethereum przekroczy sumę jej obecnej pamięci masowej. Spośród wielu popularnych ostatnio łańcuchów publicznych o wysokiej wydajności, prędkości transakcji rzędu dziesiątek tysięcy TPS mogą skutkować setkami GB nowych danych dziennie. Metoda współdzielonej redundancji danych pomiędzy wszystkimi węzłami w całej sieci ewidentnie nie jest w stanie sprostać tak dużemu obciążeniu pamięci masowej. Warstwa 1 musi znaleźć odpowiednie rozwiązanie, aby zrównoważyć wzrost TPS i koszty przechowywania danych w węzłach.

2. Wskaźniki efektywności DA

2.1 Bezpieczeństwo

W porównaniu ze strukturami przechowywania danych opartymi na bazach danych lub listach powiązanych, niezmienność technologii blockchain wynika z faktu, że nowo generowane dane można zweryfikować za pomocą danych historycznych. Dlatego zapewnienie bezpieczeństwa danych historycznych jest pierwszą kwestią, jaką należy wziąć pod uwagę przy przechowywaniu danych w warstwie DA. Oceniając bezpieczeństwo danych w systemach blockchain, często analizujemy je z perspektywy stopnia redundancji danych i metody weryfikacji dostępności danych.

  • Nadmiarowość: Nadmiarowość danych w systemie blockchain może pełnić następujące role: Po pierwsze, jeśli sieć ma większą nadmiarowość, gdy walidator musi sprawdzić status konta w bloku historycznym, aby zweryfikować bieżącą transakcję, może pobrać najwięcej próbek w celach informacyjnych i wybrać dane zarejestrowane przez większość węzłów. W tradycyjnych bazach danych dane są przechowywane wyłącznie w formie par klucz-wartość w określonym węźle, dlatego dane historyczne można zmieniać tylko w jednym węźle, a koszt ataku jest niezwykle niski. Teoretycznie, im większa redundancja, tym bardziej wiarygodne są dane. Jednocześnie im większa liczba węzłów pamięci masowej, tym mniejsze prawdopodobieństwo utraty danych. Można to również porównać do scentralizowanych serwerów, na których przechowywane są gry Web2. Po wyłączeniu wszystkich serwerów zaplecza usługa zostanie całkowicie wyłączona. Jednak im większa liczba, tym nie jest lepiej, ponieważ każda redundancja oznacza dodatkową przestrzeń dyskową, a zbyt duża redundancja danych spowoduje zbyt duże obciążenie systemu przestrzenią dyskową. Dobra warstwa DA powinna wybrać odpowiednią metodę redundancji w celu osiągnięcia równowagi między bezpieczeństwem i wydajnością pamięci masowej.

  • Weryfikacja dostępności danych: Ilość redundancji gwarantuje, że w sieci znajduje się wystarczająca ilość rekordów danych, jednak dane, które mają być wykorzystane, muszą zostać również zweryfikowane pod kątem dokładności i kompletności. Obecnie powszechnie stosowaną metodą weryfikacji w blockchainie jest algorytm kryptograficznego potwierdzenia, który zachowuje bardzo małe kryptograficzne potwierdzenie, które ma być rejestrowane przez całą sieć. To zobowiązanie uzyskuje się poprzez zmieszanie danych transakcyjnych. Aby zweryfikować autentyczność fragmentu danych historycznych, konieczne jest przywrócenie potwierdzenia kryptograficznego za pomocą danych i sprawdzenie, czy przywrócone potwierdzenie kryptograficzne jest zgodne z zapisami całej sieci. Jeżeli są spójne, weryfikacja kończy się powodzeniem. Do powszechnie stosowanych algorytmów weryfikacji kryptograficznej zaliczają się Merkle Root i Verkle Root. Wysoce bezpieczny algorytm weryfikacji dostępności danych wymaga jedynie niewielkiej ilości danych weryfikacyjnych i umożliwia szybką weryfikację danych historycznych.

2.2 Koszty magazynowania

Mając na uwadze zapewnienie podstawowego bezpieczeństwa, kolejnym zasadniczym celem, jaki musi osiągnąć warstwa DA, jest redukcja kosztów i zwiększenie wydajności. Pierwszym sposobem jest obniżenie kosztów przechowywania danych bez uwzględniania różnic w wydajności sprzętu, czyli zmniejszenie wykorzystania pamięci spowodowanego rozmiarem danych w jednostce przechowywania danych. Obecnie głównym sposobem na obniżenie kosztów przechowywania danych w technologii blockchain jest przyjęcie technologii fragmentacji i wykorzystanie pamięci masowej opartej na nagrodach, co pozwala na efektywne przechowywanie danych przy jednoczesnym zmniejszeniu liczby kopii zapasowych. Jednakże na podstawie powyższych usprawnień łatwo wywnioskować, że istnieje zależność między kosztem przechowywania danych a bezpieczeństwem danych. Zmniejszenie zajętości przestrzeni dyskowej często oznacza obniżenie poziomu bezpieczeństwa. Dlatego też doskonała warstwa DA musi zapewniać równowagę pomiędzy kosztami przechowywania danych i bezpieczeństwem danych. Ponadto, jeśli warstwa DA stanowi oddzielny łańcuch publiczny, konieczne jest także ograniczenie kosztów poprzez minimalizację procesów pośrednich zaangażowanych w wymianę danych. Dane indeksowe muszą zostać pozostawione w każdym procesie transferu na potrzeby kolejnych wywołań zapytań. Dlatego im dłuższy jest proces wywołania, tym więcej danych indeksowych pozostanie, co zwiększy koszty przechowywania. Wreszcie koszt przechowywania danych jest bezpośrednio związany z trwałością danych. Mówiąc ogólnie, im wyższy koszt przechowywania danych, tym trudniej jest publicznemu łańcuchowi trwale przechowywać dane.

2.3 Prędkość odczytu danych

Po osiągnięciu redukcji kosztów kolejnym krokiem jest zwiększenie efektywności, czyli możliwość szybkiego pobierania danych z warstwy DA, gdy są potrzebne. Proces ten składa się z dwóch etapów. Pierwszym sposobem jest wyszukanie węzłów przechowujących dane. Proces ten jest przeznaczony głównie dla łańcuchów publicznych, w których nie udało się osiągnąć spójności danych w całej sieci. Jeżeli publiczny łańcuch osiągnie synchronizację danych pomiędzy wszystkimi węzłami w całej sieci, można zignorować czasochłonność tego procesu. Po drugie, w obecnych głównych systemach blockchain, obejmujących Bitcoin, Ethereum i Filecoin, metodą przechowywania węzłów jest baza danych Leveldb. W Leveldb dane są przechowywane na trzy sposoby. Po pierwsze, natychmiast zapisane dane zostaną zapisane w pliku typu Memtable. Gdy tabela Memtable zostanie zapełniona, typ pliku zostanie zmieniony z Memtable na Immutable Memtable. Oba typy plików są przechowywane w pamięci, jednak plików niezmiennych Memtable nie można już zmieniać, można z nich jedynie odczytać dane. Gorące zasoby pamięci masowej używane w sieci IPFS przechowują dane w tej części, dzięki czemu można je szybko odczytać z pamięci, gdy zajdzie taka potrzeba. Jednakże pamięć mobilna zwykłego węzła jest często na poziomie GB, co może łatwo powodować powolny zapis. Ponadto, gdy węzeł ulegnie awarii lub napotka nietypowe sytuacje, dane w pamięci zostaną trwale utracone. Jeśli chcesz trwale przechowywać dane, musisz zapisać je na dysku SSD w postaci pliku SST. Jednak podczas odczytu danych należy je najpierw wczytać do pamięci, co znacznie zmniejsza szybkość indeksowania danych. Wreszcie w przypadku systemów wykorzystujących pamięć masową podzieloną na partycje, odzyskiwanie danych wymaga wysyłania żądań danych do wielu węzłów i przywracania danych. Proces ten spowoduje również zmniejszenie prędkości odczytu danych.

Metoda przechowywania danych Leveldb, źródło obrazu: Leveldb-handbook

2.4 Uniwersalność warstwy DA

Wraz z rozwojem DeFi i różnymi problemami giełdy CEX rośnie również zapotrzebowanie użytkowników na transakcje międzyłańcuchowe zdecentralizowanych aktywów. Niezależnie od tego, czy zostanie zastosowany mechanizm blokowania skrótu, notariusza czy międzyłańcuchowego łańcucha przekaźnikowego, nieuniknione jest jednoczesne ustalenie danych historycznych w obu łańcuchach. Kluczem do rozwiązania tego problemu jest rozdzielenie danych w obu łańcuchach, a bezpośrednia komunikacja między różnymi zdecentralizowanymi systemami jest niemożliwa. Dlatego na tym etapie zaproponowano rozwiązanie polegające na zmianie metody przechowywania warstwy DA, która przechowuje dane historyczne wielu łańcuchów publicznych w tym samym zaufanym łańcuchu publicznym. Podczas weryfikacji wystarczy wywołać dane z tego łańcucha publicznego. Wymaga to, aby warstwa DA była w stanie ustanawiać bezpieczne metody komunikacji z różnymi typami łańcuchów publicznych, innymi słowy, aby warstwa DA charakteryzowała się dużą wszechstronnością.

3. Eksploracja technologii związanych z DA

3.1 Fragmentowanie

  • W tradycyjnych systemach rozproszonych plik nie jest przechowywany w swojej pełnej formie na pojedynczym węźle. Zamiast tego oryginalne dane są dzielone na wiele bloków, a w każdym węźle przechowywany jest jeden blok. Bloki często nie są przechowywane tylko na jednym węźle, lecz mają odpowiednie kopie zapasowe na innych węzłach. W istniejących głównych systemach rozproszonych liczba kopii zapasowych jest zwykle ustawiona na 2. Ten mechanizm partycjonowania może zmniejszyć obciążenie pamięci masowej pojedynczego węzła i zwiększyć całkowitą pojemność systemu do sumy pojemności pamięci masowej każdego węzła, zapewniając jednocześnie bezpieczeństwo pamięci masowej dzięki odpowiedniej redundancji danych. Rozwiązanie Sharding stosowane w blockchain jest generalnie podobne do tego, ale istnieją różnice w szczegółach. Przede wszystkim, ponieważ każdy węzeł w blockchainie jest domyślnie niegodny zaufania, w procesie shardingu należy wykonać kopię zapasową wystarczająco dużej ilości danych w celu późniejszej oceny autentyczności danych, więc liczba kopii zapasowych tego węzła musi być znacznie większa niż 2. W idealnym przypadku w systemie blockchain, który wykorzystuje ten schemat przechowywania, jeśli całkowita liczba węzłów weryfikacyjnych wynosi T, a liczba fragmentów wynosi N, to liczba kopii zapasowych powinna wynosić T/N. Po drugie, istnieje proces przechowywania Bloku. W tradycyjnych systemach rozproszonych jest mniej węzłów, dlatego jeden węzeł jest często dostosowany do wielu bloków danych. Najpierw dane są mapowane na pierścień haszujący za pomocą spójnego algorytmu haszującego, a następnie każdy węzeł przechowuje bloki danych ponumerowane w pewnym zakresie. Można przyjąć, że węzłowi nie przypisano zadania przechowywania w określonym magazynie. W blockchainie przypisanie każdemu węzłowi bloku nie jest już zdarzeniem losowym, lecz nieuniknionym. Każdy węzeł losowo wybierze blok do przechowywania. Proces ten kończy się pobraniem wyniku skrótu danych zawierających oryginalne dane bloku i własne informacje węzła modulo liczba fragmentów. Zakładając, że każdy fragment danych jest podzielony na N bloków, rzeczywisty rozmiar pamięci każdego węzła wynosi tylko 1/N oryginału. Odpowiednie ustawienie N umożliwia osiągnięcie równowagi między zwiększonym TPS a ciśnieniem w pamięci węzła.

Metoda przechowywania danych po Shardingu, Źródło obrazu: Kernel Ventures

3.2 DAS (próbkowanie dostępności danych)

Technologia DAS stanowi dalszą optymalizację metody przechowywania danych Sharding. Podczas procesu shardingu, ze względu na proste losowe przechowywanie węzłów, blok może zostać utracony. Po drugie, w przypadku danych podzielonych na fragmenty, podczas procesu przywracania danych niezwykle istotne jest potwierdzenie ich autentyczności i integralności. W DAS te dwa problemy rozwiązuje się za pomocą kodu Eraser i wielomianowego zatwierdzania KZG.

  • Kod wymazywania: Biorąc pod uwagę ogromną liczbę węzłów weryfikacyjnych w Ethereum, prawdopodobieństwo, że blok nie zostanie zapisany przez żaden węzeł, jest bliskie zeru, ale teoretycznie istnieje możliwość wystąpienia tak ekstremalnej sytuacji. Aby zminimalizować ryzyko utraty danych, rozwiązanie to często nie dzieli oryginalnych danych bezpośrednio na bloki w celu ich zapisania. Zamiast tego oryginalne dane są najpierw mapowane na współczynniki wielomianu n-tego stopnia, a następnie na wielomianie brane są 2n punktów, z których węzłowi pozwala się losowo wybrać jeden do przechowywania. W przypadku tego wielomianu n-tego rzędu do jego odtworzenia potrzeba tylko n+1 punktów, co oznacza, że ​​węzły muszą wybrać tylko połowę bloków, aby przywrócić oryginalne dane. Kod kasujący zwiększa bezpieczeństwo przechowywanych danych i możliwości odzyskiwania danych z sieci.

  • Zobowiązanie wielomianowe KZG: Bardzo ważną częścią przechowywania danych jest weryfikacja autentyczności danych. W sieci, w której nie są używane kody Eraser, do weryfikacji można użyć wielu różnych metod. Jeśli jednak kod Eraser, o którym mowa powyżej, zostanie wprowadzony w celu zwiększenia bezpieczeństwa danych, wówczas bardziej odpowiednią metodą będzie zastosowanie wielomianowego zobowiązania KZG. Zatwierdzanie wielomianowe KZG umożliwia weryfikację zawartości pojedynczego bloku bezpośrednio w formie wielomianu, eliminując w ten sposób proces przywracania wielomianu do danych binarnych. Ogólna forma weryfikacji jest podobna do drzewa Merkle'a, ale nie wymaga danych konkretnego węzła ścieżki. Do weryfikacji autentyczności potrzebne są jedynie dane KZG Root i Block.

3.3 Metoda weryfikacji danych warstwy DA

Weryfikacja danych gwarantuje, że dane pobierane z węzła nie zostały zmodyfikowane ani utracone. Aby zminimalizować ilość danych i koszt obliczeń wymaganych w procesie weryfikacji, warstwa DA wykorzystuje obecnie strukturę drzewa jako główną metodę weryfikacji. Najprostszą formą weryfikacji jest wykorzystanie drzewa Merkle'a, które jest zapisywane w postaci kompletnego drzewa binarnego. Aby przeprowadzić weryfikację, konieczne jest zachowanie jedynie korzenia Merkle'a i wartości skrótu poddrzewa po drugiej stronie ścieżki węzła. Złożoność czasowa weryfikacji jest na poziomie O(logN) (jeśli logN nie jest dodawany z bazą, wartością domyślną jest log2(N)). Mimo że proces weryfikacji został znacznie uproszczony, ilość danych w procesie weryfikacji nadal rośnie wraz ze wzrostem danych. Aby rozwiązać problem zwiększonej ilości weryfikacji, na tym etapie zaproponowano inną metodę weryfikacji – Verkle Tree. Każdy węzeł w Drzewie Verkle'a, oprócz przechowywania wartości, posiada także Zobowiązanie Wektorowe. Autentyczność danych można szybko zweryfikować za pomocą wartości oryginalnego węzła i tego dowodu zaangażowania, bez odwoływania się do wartości innych węzłów siostrzanych. Dzięki temu liczba obliczeń dla każdej weryfikacji jest związana wyłącznie z głębokością Drzewa Verkle'a, która jest stałą wartością, co znacznie przyspiesza proces weryfikacji. Jednakże obliczenie zaangażowania wektorowego wymaga uczestnictwa wszystkich węzłów siostrzanych w tej samej warstwie, co znacznie zwiększa koszt zapisu i zmiany danych. Jednak w przypadku danych historycznych, które muszą być trwale przechowywane i zabezpieczone przed modyfikacją, a które wymagają jedynie odczytu, ale nie zapisu, Verkle Tree sprawdza się znakomicie. Ponadto drzewa Merkle’a i Verkle’a mają warianty K-arne. Ich konkretne mechanizmy implementacji są podobne, z tą różnicą, że liczba poddrzew w każdym węźle ulega zmianie. Szczegółowe porównanie wydajności można zobaczyć w poniższej tabeli.

Porównanie wydajności czasowej metody weryfikacji danych, źródło obrazu: Verkle Trees

3.4 Ogólne oprogramowanie pośredniczące DA

Ciągła ekspansja ekosystemu blockchain spowodowała ciągły wzrost liczby łańcuchów publicznych. Ze względu na zalety i niezastąpioną funkcję każdego łańcucha publicznego w jego własnym polu, ujednolicenie łańcuchów publicznych warstwy 1 w krótkim czasie jest praktycznie niemożliwe. Jednak wraz z rozwojem DeFi i różnymi problemami giełdy CEX, rośnie również zapotrzebowanie użytkowników na zdecentralizowane, międzyłańcuchowe aktywa handlowe. W związku z tym coraz większą uwagę zwraca się na wielokanałowe przechowywanie danych w warstwie DA, które może eliminować problemy bezpieczeństwa w interakcjach danych między łańcuchami. Aby jednak akceptować dane historyczne z różnych łańcuchów publicznych, warstwa DA musi udostępniać zdecentralizowany protokół umożliwiający standaryzowane przechowywanie i weryfikację strumieni danych. Na przykład kvye, oprogramowanie pośredniczące w przechowywaniu danych bazujące na Arweave, przejmuje inicjatywę w zakresie pobierania danych z łańcucha. Może przechowywać wszystkie dane łańcuchowe w Arweave w standardowej formie, aby zminimalizować różnice w procesie transmisji danych. Mówiąc relatywnie rzecz biorąc, warstwa 2, której zadaniem jest zapewnienie pamięci masowej danych warstwy DA dla pewnego łańcucha publicznego, wymienia dane za pośrednictwem wewnętrznych węzłów współdzielonych. Mimo że obniża koszty interakcji i zwiększa bezpieczeństwo, ma stosunkowo duże ograniczenia i może świadczyć usługi jedynie dla określonych łańcuchów publicznych.

4. Rozwiązanie pamięci masowej warstwy DA

4.1 Główny łańcuch DA

4.1.1 Klasa DankSharding

Ten typ rozwiązania do przechowywania danych nie ma jeszcze nazwy, a najbardziej znanym przedstawicielem jest DankSharding w sieci Ethereum, dlatego w tym artykule do określenia tego typu rozwiązań użyto klasy DankSharding. W tego typu rozwiązaniach wykorzystuje się głównie dwie technologie pamięci masowej DA wymienione powyżej, czyli Sharding i DAS. Najpierw dane są dzielone na odpowiednią liczbę części poprzez partycjonowanie, a następnie każdy węzeł wyodrębnia blok danych w formie DAS do przechowywania. Jeżeli w całej sieci jest wystarczająco dużo węzłów, możemy wybrać większą liczbę fragmentów N, tak aby ciśnienie pamięci każdego węzła wynosiło tylko 1/N oryginału, osiągając w ten sposób N-krotne zwiększenie całkowitej przestrzeni pamięci. Jednocześnie, aby zapobiec ekstremalnym sytuacjom, w których blok nie jest przechowywany w żadnym bloku, DankSharding koduje dane za pomocą Eraser Code, dzięki czemu do pełnego przywrócenia potrzebna jest tylko połowa danych. Ostatnim krokiem jest proces weryfikacji danych, który wykorzystuje strukturę drzewa Verkle'a i zobowiązanie wielomianowe w celu zapewnienia szybkiej weryfikacji.

4.1.2 Przechowywanie krótkoterminowe

W przypadku DA głównego łańcucha jednym z najprostszych sposobów przetwarzania danych jest przechowywanie danych historycznych przez krótki okres czasu. Zasadniczo blockchain działa jak publiczny rejestr, który umożliwia wprowadzanie zmian w zawartości rejestru na podstawie wspólnego monitorowania przez całą sieć, bez konieczności trwałego przechowywania danych. Biorąc za przykład Solanę, mimo że jej dane historyczne zostały zsynchronizowane z Arweave, węzeł sieci głównej przechowuje dane transakcyjne tylko z ostatnich dwóch dni. W publicznym łańcuchu bazującym na zapisach kont, dane historyczne w każdym momencie przechowują ostateczny status konta w blockchainie, co wystarcza, aby zapewnić podstawę weryfikacji zmian w następnym momencie. Podmioty biorące udział w projekcie, które przed upływem tego okresu mają szczególne potrzeby w zakresie danych, mogą przechowywać dane samodzielnie w innych zdecentralizowanych łańcuchach publicznych lub zlecić ich przechowywanie zaufanej osobie trzeciej. Oznacza to, że osoby potrzebujące dodatkowych danych muszą płacić za przechowywanie danych historycznych.

4.2 DA stron trzecich

4.2.1 Główny łańcuch dedykowany DA: EthStorage

  • Główny łańcuch dedykowany DA: Najważniejszą rzeczą w warstwie DA jest bezpieczeństwo transmisji danych. Pod tym względem DA głównego łańcucha ma najwyższy poziom bezpieczeństwa. Jednakże główny łańcuch magazynowy jest ograniczony przez przestrzeń magazynową i konkurencję o zasoby. Dlatego też, gdy ilość danych sieciowych szybko rośnie i zależy Ci na długoterminowym przechowywaniu danych, lepszym wyborem będzie zewnętrzny serwer DA. Jeśli zewnętrzny DA ma większą zgodność z siecią główną, może osiągnąć współdzielenie węzłów, a proces interakcji danych będzie również charakteryzował się większym bezpieczeństwem. Dlatego też, biorąc pod uwagę kwestie bezpieczeństwa, główny łańcuch dedykowany DA będzie miał ogromne zalety. Biorąc za przykład Ethereum, podstawowym wymogiem dla DA specyficznego dla łańcucha głównego jest kompatybilność z EVM i zapewnienie interoperacyjności między danymi i kontraktami Ethereum. Do projektów reprezentatywnych zaliczają się Topia, EthStorage itp. Spośród nich EthStorage jest najbardziej rozwinięty pod względem kompatybilności. Oprócz kompatybilności na poziomie EVM posiada także specjalnie skonfigurowane interfejsy umożliwiające połączenie z narzędziami programistycznymi Ethereum, takimi jak Remix i Hardhat, co pozwala na osiągnięcie kompatybilności na poziomie narzędzi programistycznych Ethereum.

  • EthStorage: EthStorage to publiczny łańcuch niezależny od Ethereum, ale węzły na nim działające stanowią supergrupę węzłów Ethereum. Oznacza to, że węzły obsługujące EthStorage mogą jednocześnie obsługiwać Ethereum, a EthStorage można obsługiwać bezpośrednio za pomocą kodów operacyjnych w Ethereum. W trybie przechowywania danych EthStorage, w głównej sieci Ethereum przechowywana jest tylko niewielka ilość metadanych w celu indeksowania, tworząc w istocie zdecentralizowaną bazę danych dla Ethereum. W obecnym rozwiązaniu EthStorage implementuje interakcję między główną siecią Ethereum i EthStorage poprzez wdrożenie kontraktu EthStorage w głównej sieci Ethereum. Jeśli Ethereum chce przechowywać dane, musi wywołać funkcję put() w kontrakcie. Parametrami wejściowymi są dwie zmienne bajtowe: key i data, gdzie data oznacza dane, które mają zostać zapisane, a key jest ich identyfikatorem w sieci Ethereum, co można traktować podobnie do CID istniejącego w IPFS. Po pomyślnym zapisaniu pary danych (klucz, dane) w sieci EthStorage, EthStorage wygeneruje kvldx i zwróci go do głównej sieci Ethereum, zgodnie z kluczem w Ethereum. Wartość ta odpowiada adresowi przechowywania danych w systemie EthStorage. W ten sposób problem przechowywania dużej ilości danych sprowadza się teraz do przechowywania pojedynczej pary (klucz, kvldx), co znacznie obniża koszty przechowywania danych w głównej sieci Ethereum. Jeśli musisz wywołać wcześniej zapisane dane, musisz użyć funkcji get() w EthStorage i wprowadzić kluczowy parametr. Dane w EthStorage można szybko znaleźć za pomocą kvldx przechowywanego w Ethereum.

Kontrakt EthStorage. Źródło obrazu: Kernel Ventures

  • Jeśli chodzi o konkretny sposób przechowywania danych przez węzły, EthStorage opiera się na modelu Arweave. Najpierw podzielono dużą liczbę par (k,v) z ETH. Każdy Sharding zawiera ustaloną liczbę par danych (k,v), przy czym istnieje również ograniczenie dotyczące konkretnego rozmiaru każdej pary (k,v). Zapewnia to sprawiedliwy rozkład obciążenia pracą w późniejszym procesie nagradzania górników za przechowywanie zasobów. Aby przyznać nagrody, należy najpierw sprawdzić, czy węzeł przechowuje dane. W trakcie tego procesu EthStorage podzieli Sharding (rozmiar rzędu TB) na dużą liczbę fragmentów i zachowa korzeń Merkle w głównej sieci Ethereum w celu weryfikacji. Następnie górnik musi dostarczyć identyfikator, aby wygenerować adresy kilku fragmentów za pomocą losowego algorytmu z wykorzystaniem skrótu poprzedniego bloku w EthStorage. Górnik musi dostarczyć dane dotyczące tych fragmentów, aby udowodnić, że rzeczywiście przechowuje cały Sharding. Jednakże ten nonce nie może zostać wybrany arbitralnie, w przeciwnym razie węzeł wybierze odpowiedni nonce, który odpowiada wyłącznie przechowywanemu fragmentowi i przejdzie weryfikację. Dlatego ten nonce musi sprawić, aby generowany przez niego fragment spełniał wymagania sieciowe po zmiksowaniu i haszowaniu, a nagrodę może otrzymać tylko pierwszy węzeł, który prześle nonce oraz dowód dostępu losowego.

4.2.2 Modułowa DA: Celestia

  • Moduł łańcucha bloków: Na tym etapie transakcje, które muszą zostać wykonane przez publiczny łańcuch warstwy 1, dzielą się głównie na następujące cztery części: (1) zaprojektowanie podstawowej logiki sieci, wybranie węzłów weryfikacyjnych w określony sposób, zapisanie bloków i dystrybucja nagród do osób utrzymujących sieć; (2) Pakietowanie i przetwarzanie transakcji oraz publikowanie powiązanych transakcji; (3) Zweryfikuj transakcje, które mają zostać przesłane do łańcucha i określ ich status końcowy; (4) Przechowuj i utrzymuj dane historyczne w łańcuchu bloków. W zależności od realizowanych funkcji blockchain możemy podzielić na cztery moduły, a mianowicie warstwę konsensusu, warstwę wykonawczą, warstwę rozliczeniową i warstwę dostępności danych (warstwę DA).

  • Modułowa konstrukcja łańcucha bloków: Przez długi czas te cztery moduły były zintegrowane w łańcuch publiczny, a taki łańcuch bloków nazywany jest łańcuchem bloków monolitycznych. Taka forma jest bardziej stabilna i łatwiejsza w utrzymaniu, ale jednocześnie wywiera ogromną presję na pojedynczy łańcuch publiczny. W praktyce te cztery moduły ograniczają się wzajemnie i konkurują o ograniczone zasoby obliczeniowe i pamięci masowej łańcucha publicznego. Na przykład, aby zwiększyć szybkość przetwarzania w warstwie przetwarzania, konieczne będzie zwiększenie obciążenia pamięci masowej w warstwie dostępności danych; aby zagwarantować bezpieczeństwo warstwy wykonawczej, konieczny jest bardziej złożony mechanizm weryfikacji, ale spowolni on szybkość przetwarzania transakcji. Dlatego też przy opracowywaniu łańcuchów publicznych często zachodzi konieczność dokonywania kompromisów między tymi czterema modułami. Aby przełamać wąskie gardło w poprawie wydajności łańcucha publicznego, programiści zaproponowali modułowe rozwiązanie oparte na blockchain. Główną ideą modułowego łańcucha bloków jest oddzielenie jednego lub więcej z czterech powyższych modułów i zaimplementowanie ich w oddzielnym łańcuchu publicznym. Dzięki temu możemy skupić się wyłącznie na zwiększaniu szybkości transakcji i pojemności pamięci masowej w tym publicznym łańcuchu, przełamując dotychczasowe ograniczenia ogólnej wydajności łańcucha bloków spowodowane efektem krótkiej płyty.

  • Modułowa DA: Złożona metoda oddzielająca warstwę DA od działalności blockchain i przekazująca ją do łańcucha publicznego jest uważana za wykonalne rozwiązanie problemu rosnących danych historycznych w Warstwie 1. Obecnie eksploracja w tym rejonie jest dopiero na wczesnym etapie, a najbardziej reprezentatywnym projektem jest Celestia. Jeśli chodzi o konkretną metodę przechowywania, Celestia korzysta z metody przechowywania Danksharding, która również dzieli dane na wiele bloków. Każdy węzeł wyodrębnia część danych do przechowywania i wykorzystuje wielomianowe potwierdzenie KZG w celu sprawdzenia integralności danych. Jednocześnie Celestia wykorzystuje zaawansowane dwuwymiarowe kody kasowania RS, aby nadpisać oryginalne dane w formie macierzy k*k, dzięki czemu ostatecznie do ich przywrócenia potrzeba tylko 25% oryginalnych danych. Jednakże przechowywanie danych w trybie shardingu polega w zasadzie na pomnożeniu obciążenia pamięci masowej wszystkich węzłów sieciowych przez współczynnik całkowitej ilości danych, a obciążenie pamięci masowej węzłów nadal rośnie liniowo wraz z ilością danych. Mimo że warstwa 1 nadal zwiększa prędkość transakcji, obciążenie pamięci masowej węzłów może pewnego dnia osiągnąć nieakceptowalny punkt krytyczny. Aby rozwiązać ten problem, Celestia wprowadziła komponent IPLD do przetwarzania. Dane w macierzy k*k nie są przechowywane bezpośrednio na komputerze Celestia, lecz w sieci LL-IPFS. W węźle zachowywany jest tylko kod CID danych w systemie IPFS. Gdy użytkownik zażąda fragmentu danych historycznych, węzeł wysyła odpowiedni CID do komponentu IPLD i wywołuje oryginalne dane w IPFS za pośrednictwem CID. Jeśli dane znajdują się w systemie IPFS, zostaną zwrócone za pośrednictwem komponentów i węzłów IPLD; jeśli nie istnieje, danych nie można zwrócić.

Metoda odczytu danych Celestia, Źródło obrazu: Celestia Core

  • Celestia: Biorąc Celestię za przykład, możemy dostrzec praktyczne zastosowanie modułowego blockchaina w rozwiązaniu problemu przechowywania danych w Ethereum. Węzeł Rollup wyśle ​​spakowane i zweryfikowane dane transakcji do Celestii i zapisze dane w Celestii. W trakcie tego procesu Celestia przechowuje wyłącznie dane, nie zwracając na nie większej uwagi. Na koniec, na podstawie rozmiaru przestrzeni dyskowej, węzeł Rollup zapłaci Celestii odpowiednie tokeny tia jako opłatę za przechowywanie. Pamięć masowa w systemie Celstia wykorzystuje kody DAS i kody kasowania podobne do tych w EIP4844, ale wielomianowe kody kasowania w EIP4844 zostały udoskonalone i wykorzystują dwuwymiarowe kody kasowania RS, co dodatkowo zwiększa bezpieczeństwo pamięci masowej. Do przywrócenia całości danych transakcji potrzebne jest jedynie 25% pęknięć. W istocie jest to po prostu publiczny łańcuch punktów sprzedaży z niskimi kosztami magazynowania. Jeśli ma on zostać użyty do rozwiązania problemu przechowywania historycznych danych Ethereum, konieczna będzie współpraca z Celestią wielu innych konkretnych modułów. Na przykład jeśli chodzi o Rollup, modelem Rollup zdecydowanie rekomendowanym na oficjalnej stronie Celestii jest Sovereign Rollup. W odróżnieniu od typowego Rollup na Warstwie 2, ten mechanizm jedynie oblicza i weryfikuje transakcje, czyli kończy operacje warstwy wykonawczej. Sovereign Rollup obejmuje cały proces realizacji i rozliczeń, co minimalizuje przetwarzanie transakcji w Celestii. Jeśli ogólne bezpieczeństwo Celestii jest słabsze niż bezpieczeństwo Ethereum, środek ten może zmaksymalizować bezpieczeństwo całego procesu transakcji. Jeśli chodzi o bezpieczeństwo danych, o którym mówi Celestia, najpopularniejszym obecnie rozwiązaniem jest inteligentny kontrakt oparty na moście grawitacyjnym kwantowym. W przypadku danych przechowywanych w Celestii zostanie wygenerowany Merkle Root (dowód dostępności danych) i będzie on utrzymywany w kontrakcie mostu grawitacyjnego kwantowego głównej sieci Ethereum. Za każdym razem, gdy Ethereum wywoła dane historyczne dotyczące Celestii, wynik skrótu zostanie porównany z Merkle Root. Jeżeli są takie same, oznacza to, że są to rzeczywiście prawdziwe dane historyczne.

4.2.3 Przechowywanie publicznego łańcucha DA

Jeśli chodzi o zasady techniczne głównego łańcucha DA, wiele technologii podobnych do Shardingu zostało zapożyczonych z publicznego łańcucha pamięci masowej. Niektórzy zewnętrzni administratorzy danych korzystają bezpośrednio z publicznego łańcucha pamięci masowej w celu realizacji części zadań związanych z pamięcią masową. Na przykład określone dane transakcyjne w Celestii są umieszczane w sieci LL-IPFS. W rozwiązaniu DA innej firmy, oprócz utworzenia oddzielnego łańcucha publicznego rozwiązującego problem przechowywania danych w Warstwie 1, bardziej bezpośrednim sposobem jest bezpośrednie połączenie publicznego łańcucha przechowywania danych z Warstwą 1 w celu przechowywania ogromnych ilości danych historycznych w Warstwie 1. W przypadku wydajnych blockchainów objętość danych historycznych jest jeszcze większa. Podczas pracy z pełną prędkością wolumen danych wydajnego publicznego łańcucha Solana zbliża się do 4 PG, co całkowicie przekracza zakres pamięci masowej zwykłych węzłów. Rozwiązaniem wybranym przez Solanę jest przechowywanie danych historycznych w zdecentralizowanej sieci pamięci masowej Arweave i zachowywanie jedynie 2-dniowych danych na głównych węzłach sieciowych w celu weryfikacji. Aby zagwarantować bezpieczeństwo procesu magazynowania, Solana i Arweave Chain specjalnie zaprojektowały protokół mostu magazynowego Solar Bridge. Dane zweryfikowane przez węzeł Solana zostaną zsynchronizowane z Arweave, a odpowiedni tag zostanie zwrócony. Używając tego znacznika, węzeł Solana może w dowolnym momencie przeglądać historyczne dane blockchaina Solana. W Arweave nie wszystkie węzły w całej sieci muszą utrzymywać spójność danych i wykorzystują to jako próg uczestnictwa w operacjach sieciowych. Zamiast tego przyjęto podejście oparte na nagrodzie za przechowywanie. Przede wszystkim Arweave nie wykorzystuje tradycyjnej struktury łańcuchowej do budowania bloków, ale bardziej przypomina strukturę grafu. W Arweave nowy blok nie tylko wskazuje na poprzedni blok, ale także losowo wskazuje na wygenerowany blok Recall Block. Dokładna lokalizacja bloku Recall jest ustalana na podstawie wyniku skrótu poprzedniego bloku i jego wysokości bloku. Przed wydobyciem poprzedniego bloku lokalizacja bloku Recall jest nieznana. Jednak w procesie generowania nowych bloków węzeł musi posiadać dane bloku Recall, aby móc użyć mechanizmu POW do obliczenia skrótu o określonym poziomie trudności. Nagrodę może otrzymać tylko górnik, który jako pierwszy obliczy wartość skrótu spełniającą wymagania dotyczące trudności, co zachęca górników do przechowywania jak największej ilości danych historycznych. Jednocześnie im mniej osób przechowuje historyczny blok, tym mniej konkurentów będzie miał węzeł podczas generowania nonce'a spełniającego wymagania dotyczące trudności, co zachęca górników do przechowywania bloków z mniejszą liczbą kopii zapasowych w sieci.Na koniec, aby mieć pewność, że węzły będą trwale przechowywać dane w systemie Arweave, wprowadzono mechanizm punktacji węzłów WildFire. Węzły z reguły komunikują się z węzłami, które mogą dostarczyć więcej danych historycznych w krótszym czasie, natomiast węzły o niższych ocenach często nie są w stanie uzyskać najnowszych danych o blokach i transakcjach, a tym samym nie mogą uzyskać przewagi w rywalizacji POW.

Metoda budowy bloków Arweave, źródło obrazu: Arweave Yellow-Paper

5. Porównanie kompleksowe

Następnie porównamy zalety i wady pięciu rozwiązań pamięci masowej w oparciu o cztery wymiary wskaźników wydajności DA.

  • Bezpieczeństwo: Największym źródłem problemów z bezpieczeństwem danych są ich straty powstałe w trakcie transmisji danych oraz złośliwe manipulacje ze strony nieuczciwych węzłów. Proces międzyłańcuchowy jest obszarem katastrofalnym dla bezpieczeństwa transmisji danych ze względu na niezależność i brak współdzielenia dwóch publicznych łańcuchów. Ponadto warstwa 1, która obecnie wymaga dedykowanej warstwy DA, często ma silną grupę konsensusu, a jej własne zabezpieczenia są znacznie wyższe niż w przypadku zwykłych publicznych łańcuchów pamięci masowej. Dlatego rozwiązanie DA w głównym łańcuchu charakteryzuje się większym bezpieczeństwem. Po zapewnieniu bezpieczeństwa transmisji danych kolejnym krokiem jest zapewnienie bezpieczeństwa połączeń transmisji danych. Jeśli weźmiemy pod uwagę wyłącznie krótkoterminowe dane historyczne, służące do weryfikacji transakcji, te same dane są tworzone w całej sieci w tymczasowej sieci pamięci masowej. W rozwiązaniach typu DankSharding średnia liczba kopii zapasowych danych stanowi zaledwie 1/N liczby węzłów w całej sieci. Większa redundancja danych zmniejsza ryzyko ich utraty, a także umożliwia uzyskanie większej liczby próbek referencyjnych podczas weryfikacji. Dlatego tymczasowe przechowywanie danych charakteryzuje się stosunkowo większym bezpieczeństwem. W rozwiązaniu DA innej firmy, główny łańcuch dedykowany DA wykorzystuje publiczne węzły z głównym łańcuchem, a dane mogą być bezpośrednio przesyłane przez te węzły przekaźnikowe podczas procesu międzyłańcuchowego, dzięki czemu będzie miało ono stosunkowo wyższy poziom bezpieczeństwa niż inne rozwiązania DA.

  • Koszt przechowywania: Największym czynnikiem wpływającym na koszt przechowywania jest ilość nadmiarowych danych. W rozwiązaniu krótkoterminowego przechowywania danych w głównym łańcuchu DA, przechowywanie odbywa się w formie synchronizacji danych pomiędzy wszystkimi węzłami w całej sieci. Wszelkie nowo zapisane dane muszą zostać zarchiwizowane we wszystkich węzłach całej sieci, co wiąże się z najwyższymi kosztami przechowywania. Wysokie koszty przechowywania danych sprawiają, że metoda ta nadaje się jedynie do tymczasowego przechowywania danych w sieciach o wysokim TPS. Drugą metodą jest przechowywanie Shardingu, obejmującego Sharding w łańcuchu głównym i Sharding w DA innej firmy. Ponieważ główny łańcuch często ma więcej węzłów, odpowiadający mu blok będzie miał także więcej kopii zapasowych, co oznacza, że ​​rozwiązanie Shardingu głównego łańcucha będzie droższe. Publiczny łańcuch magazynowy DA, który wykorzystuje metodę przechowywania nagród, charakteryzuje się najniższymi kosztami przechowywania. W ramach tego schematu ilość redundantnych danych często oscyluje wokół ustalonej stałej wartości. Jednocześnie wprowadzono mechanizm dynamicznej regulacji w publicznym łańcuchu pamięci masowej DA, który zachęca węzły do ​​przechowywania i tworzenia kopii zapasowych mniejszej ilości danych poprzez zwiększanie nagród za zapewnienie bezpieczeństwa danych.

  • Prędkość odczytu danych: Prędkość przechowywania danych zależy przede wszystkim od miejsca przechowywania danych w przestrzeni dyskowej, ścieżki indeksu danych oraz rozmieszczenia danych w węzłach. Spośród nich największy wpływ na szybkość ma miejsce przechowywania danych na węźle, ponieważ przechowywanie danych w pamięci lub na dysku SSD może skutkować różnicą prędkości odczytu nawet kilkudziesięciokrotnie. Publiczny łańcuch DA korzysta głównie z pamięci SSD, ponieważ obciążenie łańcucha obejmuje nie tylko dane na poziomie DA, ale także dane osobowe o dużym wykorzystaniu pamięci, takie jak filmy i zdjęcia przesyłane przez użytkowników. Jeśli sieć nie wykorzystuje dysków SSD jako przestrzeni dyskowej, trudno będzie sprostać ogromnemu obciążeniu pamięcią masową i zaspokoić potrzeby długoterminowego przechowywania danych. Po drugie, w przypadku zewnętrznych administratorów danych i głównych administratorów danych, którzy wykorzystują stan pamięci do przechowywania danych, zewnętrzny administrator danych musi najpierw wyszukać odpowiednie dane indeksu w głównym łańcuchu, a następnie przesłać dane indeksu przez łańcuch do zewnętrznego administratora danych i zwrócić dane przez most pamięci masowej. Natomiast główny łańcuch DA może bezpośrednio pobierać dane z węzła, co zapewnia większą szybkość pobierania danych. Wreszcie, w głównym łańcuchu DA, metoda Sharding wymaga wywołania Block z wielu węzłów i przywrócenia oryginalnych danych. Dlatego w porównaniu z metodą krótkotrwałego przechowywania bez partycjonowania, prędkość będzie wolniejsza.

  • Uniwersalność warstwy DA: Uniwersalność warstwy DA głównego łańcucha jest bliska zeru, ponieważ nie jest możliwe przesłanie danych z łańcucha publicznego o niewystarczającej ilości miejsca do innego łańcucha publicznego o niewystarczającej ilości miejsca. W przypadku DA stron trzecich uniwersalność rozwiązania i jego kompatybilność z określonym łańcuchem głównym to para sprzecznych wskaźników. Na przykład w rozwiązaniu DA specyficznym dla łańcucha głównego, zaprojektowanym dla konkretnego łańcucha głównego, wprowadzono wiele udoskonaleń w typie węzła i poziomach konsensusu sieciowego, aby dostosować się do łańcucha publicznego. W związku z tym usprawnienia te będą miały ogromny wpływ na utrudnienia w komunikacji z innymi sieciami publicznymi. W ramach zewnętrznej DA publiczny łańcuch DA pamięci masowej zapewnia lepszą wszechstronność w porównaniu z modułowym DA. Publiczny łańcuch magazynowy DA ma większą społeczność programistów i większe możliwości rozbudowy, dzięki czemu może dostosowywać się do sytuacji różnych łańcuchów publicznych. Jednocześnie publiczny łańcuch pamięci masowej DA uzyskuje dane aktywniej poprzez przechwytywanie pakietów niż poprzez pasywne odbieranie informacji przesyłanych z innych publicznych łańcuchów. Dzięki temu może kodować dane na swój własny sposób, realizować standaryzowane przechowywanie strumieni danych, ułatwiać zarządzanie informacjami o danych z różnych łańcuchów głównych oraz zwiększać efektywność przechowywania.

Porównanie wydajności rozwiązań pamięci masowej. Źródło obrazu: Kernel Ventures

6. Wnioski

Na tym etapie blockchain przechodzi transformację z Crypto do bardziej inkluzywnego Web3, a proces ten niesie ze sobą nie tylko wzbogacenie projektów w blockchain. Aby obsłużyć tak wiele projektów uruchomionych jednocześnie na warstwie 1, zapewniając jednocześnie działanie projektów Gamefi i Socialfi, warstwa 1 reprezentowana przez Ethereum przyjęła metody takie jak Rollup i Blobs w celu ulepszenia TPS. Wśród nowo powstających blockchainów rośnie również liczba blockchainów o wysokiej wydajności. Ale wyższy TPS oznacza nie tylko wyższą wydajność, ale także większe obciążenie pamięci masowej w sieci. W przypadku ogromnych ilości danych historycznych na tym etapie zaproponowano różne metody DA bazujące na łańcuchu głównym i podmiotach trzecich, mające na celu dostosowanie się do rosnącego zapotrzebowania na pamięć masową w łańcuchu. Każda metoda udoskonalania ma swoje zalety i wady i można ją stosować w różnych sytuacjach.

Łańcuchy bloków bazujące na płatnościach mają wyjątkowo wysokie wymagania dotyczące bezpieczeństwa danych historycznych i nie wymagają szczególnie wysokiego TPS. Jeśli ten typ łańcucha publicznego znajduje się wciąż na etapie przygotowań, można zastosować metodę przechowywania danych podobną do DankSharding, która pozwala znacznie zwiększyć pojemność pamięci masowej, gwarantując jednocześnie bezpieczeństwo. Jeśli jednak mamy do czynienia z publicznym łańcuchem, takim jak Bitcoin, który już powstał i ma dużą liczbę węzłów, istnieje ogromne ryzyko związane z pochopnym wprowadzaniem ulepszeń na poziomie konsensusu. Dlatego też w celu zrównoważenia kwestii bezpieczeństwa i przechowywania danych można zastosować główny łańcuch DA o wyższym poziomie bezpieczeństwa w pamięci masowej poza łańcuchem. Warto jednak zauważyć, że funkcje blockchain nie są statyczne, lecz podlegają ciągłym zmianom. Przykładowo, funkcje Ethereum na początku jego istnienia ograniczały się głównie do płatności i wykorzystywania inteligentnych kontraktów do prostego, zautomatyzowanego przetwarzania aktywów i transakcji. Jednak wraz z ciągłą ekspansją środowiska blockchain, do Ethereum stopniowo dodawano różne projekty Socialfi i Defi, co sprawiło, że Ethereum rozwijało się w bardziej wszechstronnym kierunku. Ostatnio, wraz z eksplozją ekosystemu inskrypcji na Bitcoinie, opłaty transakcyjne w sieci Bitcoin wzrosły blisko 20-krotnie od sierpnia. Oznacza to, że na tym etapie szybkość transakcji w sieci Bitcoin nie jest w stanie sprostać zapotrzebowaniu na transakcje, a inwestorzy mogą jedynie zwiększyć opłaty, aby transakcje były przetwarzane tak szybko, jak to możliwe. Teraz społeczność Bitcoin musi dokonać wyboru: czy zaakceptować wysokie opłaty i niską prędkość transakcji, czy obniżyć bezpieczeństwo sieci, aby zwiększyć prędkość transakcji, ale działać wbrew pierwotnemu założeniu systemu płatności. Jeśli społeczność Bitcoin wybierze drugą opcję, wówczas w obliczu rosnącej presji na dane, konieczne będzie również dostosowanie odpowiedniego rozwiązania do przechowywania danych.

Wahania opłat transakcyjnych w sieci głównej Bitcoin, źródło obrazu: OKLINK

Jeśli chodzi o łańcuchy publiczne o kompleksowych funkcjach, mają one wyższe wymagania względem TPS, a przyrost danych historycznych jest jeszcze większy. W dłuższej perspektywie rozwiązaniom opartym na technologii DankSharding trudno będzie dostosować się do szybkiego wzrostu TPS. Dlatego też bardziej odpowiednim podejściem jest migracja danych do zewnętrznego dostawcy danych w celu ich przechowywania. Spośród nich największą kompatybilność zapewnia główny łańcuch dedykowany DA, co może okazać się korzystniejsze, jeśli weźmiemy pod uwagę jedynie problem przechowywania danych w pojedynczym łańcuchu publicznym. Jednak wraz z rozkwitem publicznych łańcuchów warstwy 1, transfer zasobów między łańcuchami i interakcja danych stały się również powszechnym zajęciem społeczności blockchain. Jeśli weźmiemy pod uwagę długoterminowy rozwój całego ekosystemu blockchain, przechowywanie historycznych danych z różnych łańcuchów publicznych w tym samym łańcuchu publicznym może wyeliminować wiele problemów bezpieczeństwa w procesie wymiany i weryfikacji danych. Dlatego modularne przetwarzanie DA i przechowywanie publicznego łańcucha DA może być lepszym wyborem. Opierając się na założeniu podobnej uniwersalności, modułowe DA koncentruje się na świadczeniu usług na poziomie warstwy DA łańcucha bloków, wprowadzając bardziej dopracowane dane indeksowe do zarządzania danymi historycznymi, co pozwala na rozsądną klasyfikację danych z różnych łańcuchów publicznych i ma więcej zalet niż przechowywanie łańcuchów publicznych. Powyższe rozwiązanie nie uwzględnia jednak kosztu dostosowania warstwy konsensusu w istniejącym łańcuchu publicznym. Proces ten jest niezwykle ryzykowny. Gdy wystąpi problem, może to doprowadzić do luk w zabezpieczeniach systemu i spowodować utratę konsensusu społeczności w ramach łańcucha publicznego. Dlatego też, jeśli jest to rozwiązanie przejściowe w procesie rozszerzania łańcucha bloków, bardziej odpowiednie może okazać się najprostsze tymczasowe przechowywanie danych w postaci łańcucha głównego. Na koniec, powyższa dyskusja opiera się na wynikach rzeczywistego procesu operacyjnego. Jednakże, jeśli celem publicznego łańcucha jest rozwijanie własnego ekosystemu i przyciąganie większej liczby podmiotów i uczestników projektu, może on także faworyzować projekty wspierane i finansowane przez własną fundację. Na przykład, gdy ogólna wydajność jest równa lub nieznacznie niższa od wydajności publicznych rozwiązań do przechowywania danych w łańcuchu, społeczność Ethereum będzie również skłaniać się ku projektom warstwy 2 wspieranym przez Fundację Ethereum, takim jak EthStorage, aby móc nieustannie rozwijać ekosystem Ethereum.

Podsumowując, funkcje dzisiejszego blockchaina stają się coraz bardziej złożone, co wiąże się również ze wzrostem zapotrzebowania na przestrzeń do przechowywania danych. Gdy istnieje wystarczająca liczba węzłów weryfikacyjnych warstwy 1, nie ma potrzeby tworzenia kopii zapasowych danych historycznych przez wszystkie węzły w całej sieci. Pewne bezpieczeństwo można zagwarantować dopiero wtedy, gdy liczba kopii zapasowych osiągnie określoną wartość. Jednocześnie podział pracy w łańcuchu publicznym staje się coraz bardziej szczegółowy. Warstwa 1 odpowiada za konsensus i wykonanie, Rollup odpowiada za obliczenia i weryfikację, a do przechowywania danych używany jest osobny blockchain. Każda część może skupić się na określonej funkcji, nie ograniczając się do wydajności innych części. Jednak to, ile lub jaka część węzłów powinna przechowywać dane historyczne, aby osiągnąć równowagę między bezpieczeństwem a wydajnością, a także jak zapewnić bezpieczną interoperacyjność między różnymi blockchainami, to kwestie, nad którymi muszą zastanowić się twórcy blockchainów i które muszą stale udoskonalać. Inwestorzy mogą skupić się na głównych projektach DA specyficznych dla łańcucha Ethereum, ponieważ Ethereum ma już na tym etapie wystarczającą liczbę zwolenników i nie musi polegać na innych społecznościach, aby rozszerzać swoje wpływy. Bardziej konieczne jest udoskonalenie i rozwój własnej społeczności oraz przyciągnięcie większej liczby projektów do ekosystemu Ethereum. Jednak w przypadku publicznych łańcuchów o charakterze naśladowczym, takich jak Solana i Aptos, pojedynczy łańcuch sam w sobie nie posiada kompletnego ekosystemu, więc mogą być one bardziej skłonne do łączenia sił innych społeczności w celu zbudowania ogromnego ekosystemu międzyłańcuchowego, aby rozszerzyć swoje wpływy. Dlatego w przypadku powstającej Warstwy 1, ogólne DA stron trzecich zasługuje na większą uwagę.

Kernel Ventures to fundusz venture capital inwestujący w kryptowaluty, którego siłą napędową jest społeczność zajmująca się badaniami i rozwojem. Posiada ponad 70 inwestycji na wczesnym etapie, skoncentrowanych na infrastrukturze, oprogramowaniu pośredniczącym, zdecentralizowanych aplikacjach (dApps), zwłaszcza ZK, Rollup, DEX, modułowych blockchainach i pionach, które umożliwią przyciągnięcie miliardów przyszłych użytkowników kryptowalut, takich jak abstrakcja kont, dostępność danych, skalowalność itp. Przez ostatnie siedem lat wspieraliśmy rozwój kluczowych społeczności programistycznych i uniwersyteckich stowarzyszeń blockchain na całym świecie.

Odniesienia

  1. Celestia: Gwiaździste morze modułowego blockchaina: https://foresightnews.pro/article/detail/15497

  2. Wykorzystanie DHT i przyszłe prace: https://github.com/celestiaorg/celestia-node/issues/11

  3. Celestia-core：https://github.com/celestiaorg/celestia-core

  4. Laboratoria Solana: https://github.com/solana-labs/solana?source=post_page-----cf47a61a9274--------------------------------

  5. Przedstawiamy most SOLAR: https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2

  6. Podręcznik leveldb: https://leveldb-handbook.readthedocs.io/zh/latest/sstable.html

  7. Kuszmaul J. Drzewa Verkle[J]. Drzewa Verkle'a, 2019, 1: 1.: https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

  8. Oficjalna strona Arweave: https://www.arweave.org/

  9. Żółty papier Arweave: https://www.arweave.org/yellow-paper.pdf