Autor: Kernel Ventures Jerry Luo

Redaktorzy: Kernel Ventures Rose, Kernel Ventures Mandy, Kernel Ventures Joshua

TDR:

  1. Na wczesnym etapie blockchain utrzymanie spójności danych jest uważane za niezwykle ważne dla zapewnienia bezpieczeństwa i decentralizacji. Jednak wraz z rozwojem ekosystemu blockchain wzrasta również presja magazynowania, co prowadzi do trendu centralizacji w działaniu węzłów. W takim przypadku problem kosztów przechowywania spowodowany wzrostem TPS w warstwie 1 wymaga pilnego rozwiązania.

  2. W obliczu tego problemu programiści powinni zaproponować rozwiązanie, które w pełni uwzględnia bezpieczeństwo, koszty 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, komponenty pośrednie DA i tak dalej. Próbują zoptymalizować schemat przechowywania warstwy DA, zmniejszając redundancję danych i poprawiając efektywność sprawdzania poprawności danych.

  4. Rozwiązania DA są ogólnie podzielone na dwa typy z punktu widzenia lokalizacji przechowywania danych, a mianowicie DA z łańcucha głównego i DA stron trzecich. DA głównego łańcucha zaprojektowano z punktu widzenia regularnego czyszczenia danych i przechowywania danych podzielonych na plasterki, aby zmniejszyć obciążenie węzłów podczas przechowywania, natomiast DA innych firm zaprojektowano tak, aby zaspokajały potrzeby w zakresie przechowywania, które mają rozsądne rozwiązania dla dużych ilości danych. W rezultacie stawiamy głównie na kompromis pomiędzy kompatybilnością jednołańcuchową i kompatybilnością wielołańcuchową w DA innych firm i proponujemy trzy rodzaje rozwiązań: DA specyficzne dla łańcucha głównego, modułowe DA i DA z publicznym łańcuchem pamięci masowej.

  5. Łańcuchy publiczne typu płatniczego mają bardzo wysokie wymagania dotyczące bezpieczeństwa danych historycznych i dlatego nadają się do wykorzystania łańcucha głównego jako warstwy DA. Jednakże w przypadku sieci publicznych, które działają od długiego czasu i mają dużą liczbę górników obsługujących sieć, bardziej odpowiednie jest przyjęcie DA strony trzeciej, która nie wiąże się ze zmianą warstwy konsensusu przy stosunkowo wysokim bezpieczeństwie. W przypadku kompleksowych sieci publicznych bardziej odpowiednie jest wykorzystanie dedykowanej pamięci DA głównego łańcucha o większej pojemności danych, niższych kosztach i bezpieczeństwie. Jednakże, biorąc pod uwagę zapotrzebowanie na łańcuchy międzyłańcuchowe, modułowy DA jest również dobrym rozwiązaniem.

  6. Ogólnie rzecz biorąc, blockchain zmierza w kierunku ograniczenia redundancji danych, a także wielołańcuchowego podziału pracy.

1. Tło

Blockchain, jako rozproszona księga, musi wykonać kopię danych historycznych przechowywanych na wszystkich węzłach, aby zapewnić bezpieczeństwo i wystarczającą decentralizację przechowywania danych. Ponieważ poprawność każdej zmiany stanu jest powiązana ze stanem poprzednim (źródłem transakcji), aby zapewnić poprawność transakcji, blockchain powinien przechowywać całą historię transakcji od wygenerowania pierwszej transakcji do bieżącego transakcja. Biorąc za przykład Ethereum, nawet biorąc za średni rozmiar 20 kb na blok, całkowity rozmiar bieżących danych w Ethereum osiągnął 370 GB. W przypadku pełnego węzła, oprócz samego bloku, musi on rejestrować stan i wpływy z transakcji. Uwzględniając tę ​​część, łączna wielkość pamięci pojedynczego węzła przekroczyła 1 TB, co powoduje stopniową centralizację działania węzła.

źródło: Etherscan

Niedawna aktualizacja Ethereum w Cancun ma na celu zwiększenie TPS Ethereum do prawie 1000, w którym to momencie roczny wzrost pamięci Ethereum przekroczy sumę jego obecnej pamięci. W wysokowydajnych sieciach publicznych prędkość transakcji rzędu dziesiątek tysięcy TPS może wiązać się z dodawaniem setek GB danych dziennie. Wspólna redundancja danych wszystkich węzłów w sieci oczywiście nie jest w stanie dostosować się do takiego obciążenia przechowywania. Zatem warstwa 1 musi znaleźć odpowiednie rozwiązanie, aby zrównoważyć wzrost TPS i koszt przechowywania węzłów.

2. Wskaźniki wydajności DA

2.1 Bezpieczeństwo

W porównaniu z bazą danych lub połączoną listą, niezmienność blockchainu wynika z faktu, że nowo wygenerowane dane można zweryfikować na podstawie danych historycznych, dlatego zapewnienie bezpieczeństwa danych historycznych jest pierwszą kwestią, którą należy wziąć pod uwagę przy przechowywaniu w warstwie DA. Aby ocenić bezpieczeństwo danych w systemach blockchain, często analizujemy redundancję danych i sposób sprawdzania dostępności danych.

  • Liczba redundancji: Redundancja danych w systemie blockchain odgrywa głównie taką rolę: po pierwsze, większa redundancja w sieci może zapewnić więcej próbek do celów referencyjnych, gdy weryfikator musi sprawdzić status konta, co może pomóc węzłowi wybrać dane zarejestrowane przez większość węzłów o większym bezpieczeństwie. W tradycyjnych bazach danych, ponieważ dane są przechowywane wyłącznie w postaci par klucz-wartość w określonym węźle, zmiana danych historycznych odbywa się tylko w jednym węźle, przy niskim koszcie ataku i teoretycznie im więcej liczba zwolnień, tym wyższy stopień wiarygodności danych. Teoretycznie im większa jest redundancja, tym bardziej wiarygodne będą dane. Co więcej, im więcej węzłów, tym mniejsze prawdopodobieństwo utraty danych. Ten punkt można również porównać do scentralizowanych serwerów, na których przechowywane są gry Web2: po wyłączeniu wszystkich serwerów działających w tle nastąpi całkowite zamknięcie usługi. Jednak w przypadku większej nadmiarowości nie jest lepiej, ponieważ nadmiarowość zapewni dodatkową przestrzeń dyskową, co spowoduje zbyt duże obciążenie systemu. Dobra warstwa DA powinna wybrać odpowiedni sposób redundancji, aby osiągnąć równowagę między bezpieczeństwem a wydajnością przechowywania.

  • Sprawdzanie dostępności danych: Stopień redundancji może zapewnić wystarczającą liczbę zapisów danych w sieci, ale dane, które mają zostać wykorzystane, muszą zostać sprawdzone pod kątem dokładności i kompletności. Obecne łańcuchy bloków powszechnie wykorzystują algorytmy zobowiązań kryptograficznych jako metody weryfikacji, które po prostu zachowują niewielkie zaangażowanie kryptograficzne uzyskane w wyniku mieszania danych transakcyjnych, aby cała sieć mogła je zarejestrować. Aby sprawdzić autentyczność danych historycznych, powinniśmy spróbować odzyskać zaangażowanie w dane. Jeżeli zobowiązanie do odzyskania środków jest identyczne z zobowiązaniem pierwotnym, weryfikacja przebiega pomyślnie. Powszechnie używanymi algorytmami weryfikacji kryptograficznej są Merkle Root i Verkle Root. Algorytmy weryfikacji dostępności danych o wysokim poziomie bezpieczeństwa umożliwiają szybką weryfikację danych historycznych przy pomocy jak najmniejszej ilości danych pochodzących od osób trzecich.

2.2 Koszt przechowywania

Po zapewnieniu podstawowego bezpieczeństwa kolejnym celem warstwy DA jest redukcja kosztów i zwiększenie wydajności. Pierwszym krokiem jest zmniejszenie kosztów przechowywania wynikających ze zużycia pamięci spowodowanego przechowywaniem danych na jednostkę rozmiaru, niezależnie od różnicy w wydajności sprzętu. Obecnie głównymi sposobami na zmniejszenie kosztów przechowywania w blockchain jest zastosowanie technologii shardingu i wykorzystanie magazynu nagradzanego w celu zmniejszenia liczby kopii zapasowych danych przy jednoczesnym zachowaniu ich bezpieczeństwa. Jednakże z powyższych metod ulepszenia nietrudno zauważyć, że istnieje związek pomiędzy kosztem przechowywania a bezpieczeństwem danych, a zmniejszenie zajętości pamięci często oznacza zmniejszenie bezpieczeństwa. Dlatego doskonała warstwa DA musi zapewniać równowagę między kosztami przechowywania a bezpieczeństwem danych. Ponadto, jeśli warstwa DA jest oddzielnym łańcuchem publicznym, musi również obniżyć koszty, minimalizując pośredni proces wymiany danych, w którym każdy proces tranzytu musi pozostawić dane indeksowe do późniejszego pobrania. Zatem im dłuższy proces wywoływania, tym więcej danych indeksowych pozostanie, co zwiększy koszt przechowywania. Wreszcie koszt przechowywania danych jest bezpośrednio powiązany z trwałością danych. Ogólnie rzecz biorąc, im wyższy koszt przechowywania danych, tym trudniejsze jest trwałe przechowywanie danych w sieci publicznej.

2.3 Szybkość odczytu danych

Po osiągnięciu redukcji kosztów kolejnym krokiem jest efektywność, czyli możliwość szybkiego przywołania danych z warstwy DA w razie potrzeby. Proces ten składa się z dwóch etapów. Pierwszy polega na wyszukiwaniu węzłów do przechowywania danych, głównie w przypadku łańcuchów publicznych, które nie osiągnęły spójności danych w sieci. Jeżeli łańcuch publiczny osiągnął synchronizację danych węzłów w sieci, czasochłonność tego proces można zignorować. Następnie, w głównych systemach blockchain na tym etapie, w tym Bitcoin, Ethereum i Filecoin, metodą przechowywania węzłów jest cała baza danych Leveldb. W Leveldb dane są przechowywane na trzy sposoby. Po pierwsze, dane zapisywane na bieżąco są przechowywane w plikach typu Memtable do momentu zapełnienia Memtable, następnie typ pliku zostaje zmieniony z Memtable na Immutable Memtable. Obydwa typy są przechowywane w pamięci, ale pliki Immutable Memtable są tylko do odczytu. Hot Storage używany w sieci IPFS przechowuje dane w tej części sieci, dzięki czemu można je szybko odczytać z pamięci w momencie wywołania, jednak przeciętny węzeł ma jedynie GB pamięci wymiennej, którą można łatwo spowolnić, a gdy węzeł ulegnie awarii, dane w pamięci zostaną trwale utracone. Jeśli chcesz trwałego przechowywania danych, musisz przechowywać dane w postaci plików SST na dysku półprzewodnikowym (SSD), ale podczas odczytu danych musisz najpierw odczytać dane do pamięci, co znacznie zmniejsza prędkość indeksowania danych. Wreszcie, w przypadku systemu korzystającego z fragmentowania pamięci, przywracanie danych wymaga wysyłania żądań danych do wielu węzłów i ich przywracania, co również spowalnia odczyt danych.

Źródło: Podręcznik Leveldb

2.4 Uogólnienie warstwy DA

Wraz z rozwojem DeFi i różnymi problemami CEX rosną wymagania użytkowników dotyczące transakcji międzyłańcuchowych zdecentralizowanych aktywów. Niezależnie od tego, czy zastosujemy mechanizm międzyłańcuchowy, czyli blokowanie hash, notarialny czy łańcuch przekaźnikowy, nie możemy uniknąć jednoczesnego określania danych historycznych w dwóch łańcuchach. Kluczem do rozwiązania tego problemu jest rozdzielenie danych w obu łańcuchach, których nie można bezpośrednio przekazać w różnych zdecentralizowanych systemach. Dlatego 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 i podczas weryfikacji musi jedynie wywołać dane z tego łańcucha publicznego. Wymaga to, aby warstwa DA była w stanie nawiązać bezpieczną komunikację z różnymi typami łańcuchów publicznych, co oznacza, że ​​warstwa DA ma dobrą wszechstronność.

3. Techniki dotyczące DA

3.1 Fragmentowanie

W tradycyjnych systemach rozproszonych plik nie jest przechowywany w pełnej postaci w węźle, ale w celu podzielenia oryginalnych danych na wiele bloków i przechowywania ich w każdym węźle. Ponadto blok często jest nie tylko przechowywany w jednym węźle, ale pozostawia odpowiednią kopię zapasową w innych węzłach. W istniejących głównych systemach rozproszonych liczba kopii zapasowych jest zwykle ustawiana na 2. Ten mechanizm shardingu może zmniejszyć obciążenie poszczególnych węzłów, zwiększyć całkowitą pojemność systemu do sumy pojemności każdego węzła, a przy jednocześnie zapewniają bezpieczeństwo przechowywania poprzez odpowiednią redundancję danych. Schemat shardingu zastosowany w blockchain jest ogólnie podobny do tradycyjnych systemów rozproszonych, ale istnieją różnice w niektórych szczegółach. Po pierwsze, ponieważ domyślne węzły w łańcuchu bloków są niewiarygodne, proces realizacji shardingu wymaga wystarczająco dużej ilości kopii zapasowych danych do 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 przyjmuje ten schemat przechowywania, jeśli całkowita liczba węzłów uwierzytelniających wynosi T, a liczba fragmentów wynosi N, liczba kopii zapasowych powinna wynosić T/N. Po drugie, jeśli chodzi o proces przechowywania bloku, tradycyjny system rozproszony z mniejszą liczbą węzłów często działa w trybie, w którym węzeł dostosowuje się do wielu bloków danych. Po pierwsze, dane są mapowane do pierścienia mieszającego za pomocą spójnego algorytmu mieszającego, a następnie każdy węzeł przechowuje pewien zakres ponumerowanych bloków z przypisaniami pierścienia mieszającego. W systemie można przyjąć, że jeden węzeł nie ma zadania składowania w określonej pamięci. W łańcuchu bloków blok pamięci nie jest już przypadkowym, ale nieuniknionym wydarzeniem dla węzłów. Każdy węzeł losowo wybierze blok do przechowywania w łańcuchu bloków, a proces zakończy się wynikiem mieszania danych zmieszanych z informacjami węzła w liczbie modulo. Zakładając, że każde dane są podzielone na N bloków, rzeczywisty rozmiar pamięci każdego węzła wynosi tylko 1/N. Ustawiając odpowiednio N, możemy osiągnąć równowagę pomiędzy wzrostem TPS a obciążeniem pamięci węzłowej.

Źródło: Kernel Ventures

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

Technologia DAS to dalsza optymalizacja sposobu przechowywania oparta na shardingu. W procesie shardingu, ze względu na proste losowe przechowywanie węzłów, może wystąpić utrata bloku. Po drugie, w przypadku danych po fragmentowaniu bardzo ważne jest również to, jak potwierdzić autentyczność i integralność danych podczas procesu przywracania. W DAS te dwa problemy rozwiązuje się za pomocą kodu Eraser i zaangażowania wielomianu KZG.

  • Kod kasowania: biorąc pod uwagę dużą liczbę zweryfikowanych węzłów w Ethereum, możliwe jest, że blok nie zostanie zapisany przez żaden węzeł, chociaż jest to zdarzenie prawdopodobny. Aby zmniejszyć ryzyko braku pamięci, zamiast kroić surowe dane na bloki, schemat ten odwzorowuje surowe dane na współczynniki wielomianu n-tego stopnia, następnie bierze 2n punktów na wielomian i pozwala węzłom losowo wybrać jeden z je przechowywać. W przypadku tego wielomianu n-tego stopnia do redukcji potrzebnych jest tylko n+1 punktów, a zatem węzły muszą wybrać tylko połowę bloków, abyśmy mogli zrealizować redukcję oryginalnych danych. Kod Eraser poprawia bezpieczeństwo przechowywania danych i zdolność sieci do odzyskiwania danych.

  • Zobowiązanie wielomianowe KZG: Bardzo ważnym aspektem przechowywania danych jest weryfikacja autentyczności danych. W sieciach nie korzystających z kodu Eraser można zastosować różne metody weryfikacji, jednak jeśli powyższy kod Eraser zostanie wprowadzony w celu poprawy bezpieczeństwa danych, wówczas bardziej właściwe będzie zastosowanie zaangażowania wielomianowego KZG, które może zweryfikować zawartość pojedynczego blokować bezpośrednio w postaci wielomianu, eliminując w ten sposób potrzebę redukcji wielomianu do danych binarnych. Zaangażowanie wielomianowe KZG może bezpośrednio weryfikować zawartość pojedynczego bloku w postaci wielomianów, eliminując w ten sposób potrzebę redukcji wielomianów do danych binarnych, a ogólna forma weryfikacji jest podobna do tej z Merkle Tree, ale nie wymaga specjalnych Dane węzła ścieżki i wymagają jedynie danych korzenia KZG i danych bloku w celu sprawdzenia autentyczności bloku.

3.3 Metoda walidacji danych w DA

Walidacja danych zapewnia, że ​​dane wywoływane z węzła są dokładne i kompletne. Aby zminimalizować ilość danych i koszty obliczeniowe wymagane w procesie walidacji, warstwa DA wykorzystuje obecnie strukturę drzewiastą jako główną metodę walidacji. Najprostszą formą jest użycie do weryfikacji drzewa Merkle, które wykorzystuje formę kompletnych rekordów drzewa binarnego, wystarczy zachować korzeń Merkle i można zweryfikować wartość skrótu poddrzewa po drugiej stronie ścieżki węzła, złożoność czasowa weryfikacji wynosi poziom O(logN) (logN to domyślny log2(N)). Chociaż proces walidacji został znacznie uproszczony, ogólnie rzecz biorąc, ilość danych potrzebnych do procesu walidacji wciąż rośnie wraz ze wzrostem ilości danych. Aby rozwiązać problem rosnącego wolumenu walidacji, na tym etapie proponowana jest inna metoda walidacji, Verkle Tree, w której każdy węzeł w Verkle Tree nie tylko przechowuje wartość, ale także dołącza zobowiązanie wektorowe, które może szybko zweryfikować autentyczność danych przy użyciu wartości węzła pierwotnego i dowodu zaangażowania, bez konieczności wywoływania wartości innych węzłów siostrzanych, co ułatwia i przyspiesza obliczenia każdej walidacji. To sprawia, że ​​liczba obliczeń dla każdej weryfikacji jest powiązana jedynie z głębokością drzewa Verkle, która jest stałą stałą, co znacznie przyspiesza szybkość weryfikacji. Jednak obliczenie zaangażowania wektorowego wymaga udziału wszystkich węzłów siostrzanych w tej samej warstwie, co znacznie zwiększa koszt zapisu i zmiany danych. Jednakże w przypadku danych takich jak dane historyczne, które są trwale przechowywane i nie można nimi manipulować, a także można je tylko odczytać, ale nie można ich zapisać, drzewo Verkle jest wyjątkowo odpowiednie. Ponadto samo drzewo Merkle i Verkle Tree mają K-aryjną formę wariantów, konkretna implementacja mechanizmu jest podobna, wystarczy zmienić liczbę poddrzew w każdym węźle, konkretne porównanie wydajności można zobaczyć w poniższej tabeli.

Źródło: Verkle Trees

3.4 Ogólne oprogramowanie pośredniczące DA

Ciągła ekspansja ekosystemu blockchain spowodowała powstanie coraz większej liczby łańcuchów publicznych. Ze względu na zalety i niezastępowalność każdego łańcucha publicznego w odpowiednich obszarach, nie jest możliwe ujednolicenie łańcuchów publicznych warstwy 1 w krótkim czasie. Jednak wraz z rozwojem DeFi i problemami CEX rośnie zapotrzebowanie użytkowników na zdecentralizowane aktywa do handlu międzyłańcuchowego. Dlatego coraz większą uwagę zwraca się na wielołańcuchowe przechowywanie danych w warstwie DA, które może wyeliminować problemy bezpieczeństwa w interakcjach danych między łańcuchami. Aby jednak akceptować dane historyczne z różnych łańcuchów publicznych, konieczne jest, aby warstwa DA zapewniła zdecentralizowane protokoły do ​​standaryzowanego przechowywania i walidacji przepływu danych. Na przykład kvye, oprogramowanie pośredniczące w przechowywaniu oparte na Arweave, przyjmuje metodę aktywnego indeksowania danych z głównych łańcuchów i może przechowywać dane ze wszystkich łańcuchów w ustandaryzowanej formie w Arweave, aby zminimalizować różnice w transmisji danych proces. Dla porównania warstwa 2, która specjalizuje się w zapewnianiu przechowywania danych w warstwie DA dla określonego łańcucha publicznego, przeprowadza interakcję z danymi za pośrednictwem wewnętrznych węzłów współdzielonych. Choć obniża koszty interakcji i poprawia bezpieczeństwo, ma większe ograniczenia i może świadczyć usługi tylko określonym sieciom publicznym.

4. Metody przechowywania DA

4.1 Łańcuch główny DA

4.1.1 Podobny do DankSharding

Nie ma ostatecznej nazwy dla tego typu schematu przechowywania, ale najbardziej znaną z nich jest Dank Sharding na Ethereum, dlatego w tym artykule używamy terminu podobnego do Dank Sharding w odniesieniu do tego typu schematu. Ten typ schematu wykorzystuje głównie dwie wspomniane powyżej techniki przechowywania DA, sharding i DAS, po pierwsze dane są dzielone na odpowiednią liczbę udziałów poprzez sharding, a następnie każdy węzeł wyodrębnia blok danych w postaci DAS do przechowywania. W przypadku, gdy w całej sieci jest wystarczająca liczba węzłów, możemy przyjąć większą liczbę wycinków N, tak aby ciśnienie magazynowania w każdym węźle wynosiło tylko 1/N pierwotnego, realizując w ten sposób N-krotne zwiększenie całkowitej pamięci przestrzeń. Jednocześnie, aby zapobiec skrajnemu przypadkowi, w którym blok nie jest przechowywany w żadnym bloku, Dank Sharding koduje dane przy użyciu kodu Eraser Code, który do pełnego przywrócenia wymaga tylko połowy danych. Na koniec dane są weryfikowane przy użyciu struktury Verkle Tree z zobowiązaniami wielomianowymi w celu uzyskania szybkich sum kontrolnych.

4.1.2 Tymczasowe przechowywanie

Dla DA głównego łańcucha jednym z najprostszych sposobów postępowania z danymi jest przechowywanie danych historycznych przez krótki okres czasu. Zasadniczo blockchain działa jak księga publiczna, w której wprowadzane są zmiany w zawartości księgi w obecności całej sieci i nie ma potrzeby stałego przechowywania. Na przykład w przypadku Solany, chociaż jej dane historyczne są zsynchronizowane z Arweave, główne węzły sieci przechowują jedynie dane transakcyjne z ostatnich dwóch dni. W łańcuchu publicznym opartym na rekordach rachunków każdy moment danych historycznych zachowuje ostateczny stan konta na blockchainie, który jest wystarczający, aby stanowić podstawę do weryfikacji zmian w kolejnym momencie. Ci, którzy mają szczególne potrzeby w zakresie danych przed tym czasem, mogą przechowywać je w innych zdecentralizowanych łańcuchach publicznych lub przekazać zaufanej stronie trzeciej. Innymi słowy, ci, którzy mają dodatkowe potrzeby w zakresie danych, będą musieli zapłacić za przechowywanie danych historycznych.

4.2 DA strony trzeciej

4.2.1 DA dla głównego łańcucha: EthStorage

  • DA dla łańcucha głównego: Najważniejszą rzeczą dla warstwy DA jest bezpieczeństwo transmisji danych, a DA o najwyższym bezpieczeństwie to DA głównego łańcucha, ale pamięć głównego łańcucha jest ograniczona przestrzenią do przechowywania i konkurencją ze strony zasobów, więc gdy ilość danych w sieci szybko rośnie, zewnętrzny DA jest lepszym wyborem, jeśli chce realizować długoterminowe przechowywanie danych. Jeśli zewnętrzny DA ma wyższą kompatybilność z siecią główną, może realizować współdzielenie węzłów, a proces interakcji danych będzie miał większe bezpieczeństwo. Dlatego też, przy założeniu uwzględnienia bezpieczeństwa, dedykowany DA dla głównego łańcucha będzie miał ogromną przewagę. Biorąc za przykład Ethereum, jednym z podstawowych wymagań dla DA dedykowanego dla głównego łańcucha jest to, że może być kompatybilny z EVM w celu zapewnienia interoperacyjności z danymi i kontraktami Ethereum, a reprezentatywne projekty obejmują Topia, EthStorage itp. Wśród nich EthStorage jest najbardziej kompatybilnym DA pod względem kompatybilności. Reprezentatywne projekty obejmują Topia, EthStorage i tak dalej. Wśród nich EthStorage jest najlepiej rozwinięty pod względem kompatybilności, ponieważ oprócz kompatybilności z EVM skonfigurował również odpowiednie interfejsy do współpracy z Remixem, Hardhat i innymi narzędziami programistycznymi Ethereum w celu zapewnienia kompatybilności z narzędziami programistycznymi Ethereum.

  • EthStorage: EthStorage jest łańcuchem publicznym niezależnym od Ethereum, ale działające w nim węzły stanowią supergrupę węzłów Ethereum, co oznacza, że ​​węzły, na których działa EthStorage, mogą również jednocześnie uruchamiać Ethereum. Co więcej, możemy również bezpośrednio obsługiwać EthStorage za pomocą kodów operacyjnych w Ethereum. Model przechowywania EthStorage zachowuje tylko niewielką ilość metadanych do indeksowania w głównej sieci Ethereum, tworząc zasadniczo zdecentralizowaną bazę danych dla Ethereum. W obecnym rozwiązaniu EthStorage wdraża kontrakt EthStorage na głównym Ethereum, aby zrealizować interakcję pomiędzy głównym Ethereum a EthStorage. Jeśli Ethereum chce zdeponować dane, musi wywołać funkcję put() w kontrakcie, a parametrami wejściowymi są zmienne dwubajtowe key, data, gdzie dane reprezentują dane do zdeponowania, a kluczem jest ich tożsamość w Sieć Ethereum, którą można uznać za podobną do istnienia CID w IPFS. Po pomyślnym zapisaniu pary danych (klucz, dane) w sieci EthStorage, EthStorage wygeneruje wartość kvldx, która ma zostać zwrócona do sieci hosta Ethereum, co odpowiada kluczowi w sieci Ethereum, a wartość ta odpowiada adresowi przechowywania danych w EthStorage, dzięki czemu pierwotny problem przechowywania dużej ilości danych można teraz zmienić na przechowywanie pojedynczego (klucza, kvldx). (klucz, kvldx), co znacznie zmniejsza koszt przechowywania głównej sieci Ethereum. Jeśli chcesz wywołać wcześniej zapisane dane, musisz użyć funkcji get() w EthStorage i wprowadzić parametr key, a następnie możesz szybko wyszukać dane w EthStorage za pomocą kvldx przechowywanego w Ethereum.

Źródło: Kernel Ventures

  • Jeśli chodzi o sposób przechowywania danych przez węzły, EthStorage uczy się na podstawie modelu Arweave. Po pierwsze, duża liczba par (k,v) z ETH jest poddawana fragmentacji, a każdy fragment zawiera stałą liczbę par (k,v), z których istnieje ograniczenie rozmiaru każdej pary (k,v) parę, aby zapewnić sprawiedliwe obciążenie pracą w procesie przechowywania nagród dla górników. Aby wystawić nagrodę, należy najpierw sprawdzić, czy węzeł przechowuje dane. W tym procesie EthStorage podzieli fragment (rozmiar TB) na wiele części i zachowa korzeń Merkle w głównej sieci Ethereum w celu weryfikacji. Następnie górnik musi podać wartość jednorazową, aby wygenerować kilka fragmentów za pomocą losowego algorytmu z hashem poprzedniego bloku w EthStorage, a górnik musi podać dane tych fragmentów, aby udowodnić, że przechował cały sharding, ale tej wartości jednorazowej nie można wybrać dowolnie, w przeciwnym razie węzeł wybierze odpowiednią wartość jednorazową odpowiadającą przechowywanym przez niego fragmentom i przejdzie weryfikację. Jednak ta wartość jednorazowa nie może zostać wybrana losowo, w przeciwnym razie węzeł wybierze odpowiednią wartość jednorazową, która odpowiada tylko jego przechowywanym fragmentom i w ten sposób przejdzie weryfikację, więc ta wartość jednorazowa musi utworzyć wygenerowane fragmenty po zmieszaniu i haszowaniu, aby wartość trudności spełniała wymagania sieci i tylko pierwszy węzeł, który prześle wartość jednorazową i dowód dostępu swobodnego, może otrzymać nagrodę.

4.2.2 Modularyzacja DA: Celsetia

  • Moduł Blockchain: Transakcje przeprowadzane w łańcuchu publicznym warstwy 1 są podzielone na cztery następujące części: (1) projektowanie podstawowej logiki sieci, wybieranie w określony sposób węzłów walidacyjnych, zapisywanie bloków i przydzielanie nagród opiekunom sieci; (2) transakcje pakowania i przetwarzania oraz transakcje powiązane z publikowaniem; (3) zatwierdzanie transakcji do przesłania do blockchainu i ustalanie ich ostatecznego statusu; (4) przechowywanie i utrzymywanie danych historycznych na blockchainie. Ze względu na różne wykonywane funkcje możemy podzielić blockchain na cztery moduły, warstwę konsensusu, warstwę wykonawczą, warstwę rozliczeniową i warstwę dostępności danych (warstwa DA).

  • Modularna konstrukcja Blockchain: przez długi czas te cztery moduły były zintegrowane w jeden publiczny łańcuch, taki blockchain nazywany jest monolitycznym blockchainem. Ta forma jest bardziej stabilna i łatwiejsza w utrzymaniu, ale wywiera również ogromną presję na pojedynczy łańcuch publiczny. W praktyce cztery moduły ograniczają się nawzajem i konkurują o ograniczone zasoby obliczeniowe i pamięciowe łańcucha publicznego. Na przykład zwiększenie szybkości przetwarzania warstwy przetwarzania spowoduje większe obciążenie pamięci w warstwie dostępności danych; zapewnienie bezpieczeństwa warstwy wykonawczej wymaga bardziej złożonego mechanizmu weryfikacji, ale spowalnia szybkość przetwarzania transakcji. Dlatego rozwój łańcucha publicznego często wiąże się z kompromisem między tymi czterema modułami. Aby przełamać to wąskie gardło w poprawie wydajności łańcucha publicznego, programiści zaproponowali modułowe rozwiązanie typu blockchain. Podstawową ideą modułowego blockchainu jest usunięcie jednego lub kilku z czterech wymienionych powyżej modułów i przekazanie ich oddzielnemu łańcuchowi publicznemu w celu wdrożenia. W ten sposób łańcuch publiczny może skoncentrować się na poprawie szybkości transakcji lub pojemności pamięci, przełamując dotychczasowe ograniczenia ogólnej wydajności blockchainu ze względu na efekt krótkiej płytki.

  • Modułowy DA: Złożone podejście polegające na oddzieleniu warstwy DA od biznesu blockchain i umieszczeniu jej w oddzielnym łańcuchu publicznym jest uważane za realne rozwiązanie w przypadku rosnących danych historycznych warstwy 1. Na tym etapie eksploracja w tym obszarze jest jeszcze na wczesnym etapie, a najbardziej reprezentatywnym projektem jest Celestia, która wykorzystuje metodę przechowywania danych Sharding, która również dzieli dane na wiele bloków, a każdy węzeł wyodrębnia ich część dla przechowywania i wykorzystuje zobowiązanie wielomianowe KZG do weryfikacji integralności danych. Jednocześnie Celestia wykorzystuje zaawansowane dwuwymiarowe kody korekcyjne RS do przepisania oryginalnych danych w postaci macierzy k*k, co docelowo wymaga odzyskania jedynie 25% oryginalnych danych. Jednakże magazynowanie danych podzielonych polega zasadniczo na pomnożeniu zapotrzebowania węzłów w sieci na przechowywanie danych przez współczynnik całkowitej objętości danych, a obciążenie węzłów w dalszym ciągu rośnie liniowo wraz z objętością danych. W miarę ciągłego ulepszania szybkości transakcji w warstwie 1 obciążenie węzłów może pewnego dnia osiągnąć niedopuszczalny próg. Aby rozwiązać ten problem, w Celestii wprowadzono komponent IPLD. Zamiast przechowywać dane w macierzy k*k bezpośrednio na Celestii, dane są przechowywane w sieci LL-IPFS, a w węźle przechowywany jest jedynie kod CID danych. Kiedy użytkownik żąda fragmentu danych historycznych, węzeł wysyła odpowiedni identyfikator CID do komponentu IPLD, który służy do wywoływania oryginalnych danych w IPFS. Jeśli dane istnieją w IPFS, są zwracane przez komponent IPLD i węzeł. Jeśli nie istnieje, dane nie mogą zostać zwrócone.

Źródło: Celestia Core

  • Celestia: Biorąc Celestię jako przykład, widzimy zastosowanie modułowego blockchainu w rozwiązywaniu problemu przechowywania Ethereum, węzeł Rollup wyśle ​​spakowane i zweryfikowane dane transakcyjne do Celestii i będzie przechowywać dane na Celestii, podczas procesu Celestia przechowuje tylko danych bez zbytniej percepcji. W tym procesie Celestia po prostu przechowuje dane bez ich wykrywania, a na koniec, w zależności od wielkości przestrzeni dyskowej, węzeł Rollup zapłaci Celestii odpowiednie tokeny tia jako opłatę za przechowywanie. Pamięć w Celestii wykorzystuje podobny kod DAS i debugowanie jak w EIP4844, ale wielomianowy kod debugowania w EIP4844 został zaktualizowany tak, aby korzystał z dwuwymiarowego kodu debugowania RS, co ponownie zwiększa bezpieczeństwo pamięci i tylko 25% ułamków są potrzebne do odzyskania całości danych transakcji. Zasadniczo jest to publiczny łańcuch POS z niskimi kosztami przechowywania, a jeśli ma zostać zrealizowany jako rozwiązanie problemu przechowywania danych historycznych w Ethereum, do współpracy z Celestią potrzebnych jest wiele innych specyficznych modułów. Na przykład, jeśli chodzi o rollup, jednym z modeli rollupów wysoce zalecanych na oficjalnej stronie Celestii jest Sovereign Rollup, który różni się od zwykłego rollupu na warstwie 2, który może jedynie obliczać i weryfikować transakcje, po prostu kończąc warstwę wykonania i obejmuje cały proces egzekucyjny i rozliczeniowy, co minimalizuje konieczność przeprowadzania procesu egzekucyjnego i rozliczeniowego na Celestii. Minimalizuje to przetwarzanie transakcji na Celestii, co maksymalizuje ogólne bezpieczeństwo procesu transakcyjnego, gdy ogólne bezpieczeństwo Celestii jest słabsze niż Ethereum. Jeśli chodzi o bezpieczeństwo danych wywoływanych przez Celestię w głównej sieci Ethereum, najbardziej popularnym rozwiązaniem jest inteligentny kontrakt Quantum Gravity Bridge. Dla danych przechowywanych na platformie Celestia wygeneruje ona Merkle Root (certyfikat dostępności danych) i będzie przechowywać go w umowie Quantum Gravity Bridge w głównej sieci EtherCenter. Kiedy EtherCenter za każdym razem wywoła dane historyczne Celestii, porówna wynik mieszania z korzeniem Merkle i jeśli będzie zgodny, oznacza to, że rzeczywiście są to prawdziwe dane historyczne.

4.2.3 Łańcuch magazynowania DA

Jeśli chodzi o zasady techniczne głównych DA, wiele technik podobnych do shardingu zostało zapożyczonych z publicznych łańcuchów pamięci masowej. W zewnętrznych DA niektóre z nich realizują nawet część zadań związanych z przechowywaniem bezpośrednio za pomocą publicznych łańcuchów przechowywania, na przykład określone dane transakcyjne w Celestii są umieszczane w sieci LL-IPFS. W rozwiązaniach zewnętrznych dostawców danych, poza budowaniem oddzielnego łańcucha publicznego w celu rozwiązania problemu przechowywania w warstwie 1, bardziej bezpośrednim sposobem jest bezpośrednie połączenie publicznego łańcucha pamięci masowej z warstwą 1 w celu przechowywania ogromnych danych historycznych w warstwie 1. W przypadku wysokowydajnego blockchaina ilość danych historycznych jest jeszcze większa, przy pracy z pełną prędkością wolumen danych wysokowydajnego łańcucha publicznego Solana jest bliski 4 PG, co całkowicie wykracza poza zakres przechowywania zwykłych węzłów. Solana wybiera rozwiązanie polegające na przechowywaniu danych historycznych w zdecentralizowanej sieci magazynowania Arweave i przechowuje dane tylko przez 2 dni w węzłach sieci głównej w celu weryfikacji. Aby zapewnić bezpieczeństwo procesu przechowywania, Solana i sieć Arweave zaprojektowały protokół mostu pamięci masowej, Solar Bridge, który synchronizuje zweryfikowane dane z węzłów Solana do Arweave i zwraca odpowiedni tag, co pozwala węzłom Solana przeglądać dane historyczne blockchain Solana w dowolnym momencie. Węzeł Solana może przeglądać dane historyczne z dowolnego momentu w łańcuchu bloków Solana. W Arweave zamiast wymagać od węzłów w sieci utrzymywania spójności danych jako konieczności uczestnictwa, sieć przyjmuje podejście polegające na przechowywaniu nagród. Po pierwsze, Arweave nie wykorzystuje tradycyjnej struktury łańcuchowej do budowania bloków, ale bardziej przypomina strukturę wykresu. W Arweave nowy blok będzie nie tylko wskazywał poprzedni blok, ale także losowo wskazywał wygenerowany blok. Blok Recall, którego dokładna lokalizacja jest określana na podstawie wyniku mieszania poprzedniego bloku i jego wysokości bloku oraz lokalizacji bloku Recall. blok jest nieznany, dopóki poprzedni blok nie zostanie wydobyty. Jednak w procesie generowania nowych bloków węzły muszą posiadać dane bloku Recall, aby móc skorzystać z mechanizmu POW do obliczenia hasha o określonym stopniu trudności i tylko górnik, który jako pierwszy obliczy hash spełniający trudność może zostać nagrodzona, co zachęca górników do przechowywania jak największej ilości danych historycznych. Jednocześnie im mniej osób przechowuje dany blok historyczny, tym mniej konkurentów będzie miał węzeł przy generowaniu wartości jednorazowej odpowiadającej trudnościom, 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 przechowują dane na stałe, w Arweave wprowadzono mechanizm oceniania węzłów WildFire. Węzły będą wolały komunikować się z węzłami, które mogą szybciej i szybciej dostarczać dane historyczne, podczas gdy węzły o niższych ocenach nie będą w stanie uzyskać za pierwszym razem najnowszych danych blokowych i transakcyjnych, przez co nie uzyskają przewagi w konkurencji POW.

Źródło: żółta księga Arweave

5. Porównanie syntetyczne

Porównamy zalety i wady każdego z pięciu rozwiązań pamięci masowej pod kątem czterech wymiarów wskaźników wydajności DA.

  • Bezpieczeństwo: największym źródłem problemów związanych z bezpieczeństwem danych jest utrata danych spowodowana procesem transmisji danych i złośliwą ingerencją ze strony nieuczciwych węzłów, a proces międzyłańcuchowy jest obszarem bezpieczeństwa transmisji danych najbardziej dotkniętym ze względu na niezależność dwóch publicznych łańcuchy i stan nie jest współdzielony. Ponadto Warstwa 1, która na tym etapie wymaga wyspecjalizowanej warstwy DA, często posiada silną grupę konsensusową, a jej bezpieczeństwo będzie znacznie wyższe niż w przypadku zwykłych publicznych łańcuchów pamięci masowej. Dlatego rozwiązanie DA głównego łańcucha ma większe bezpieczeństwo. Po zapewnieniu bezpieczeństwa transmisji danych kolejnym krokiem jest zapewnienie bezpieczeństwa danych połączeń. Biorąc pod uwagę jedynie krótkoterminowe dane historyczne służące do weryfikacji transakcji, te same dane są archiwizowane przez całą sieć w sieci tymczasowego przechowywania danych, podczas gdy średnia liczba kopii zapasowych danych w schemacie przypominającym DankSharding wynosi tylko 1/N liczby węzłów w całej sieci, co oznacza, że ​​większa redundancja danych może sprawić, że dane będą mniej podatne na utratę, a jednocześnie może zapewnić więcej próbek referencyjnych do weryfikacji. Dlatego przechowywanie tymczasowe będzie zapewniać większe bezpieczeństwo danych. W schemacie DA strony trzeciej, ze względu na węzły publiczne wykorzystywane w łańcuchu głównym, dane mogą być bezpośrednio przesyłane przez te węzły przekaźnikowe w procesie cross-chainingu, dzięki czemu będą miały również stosunkowo wyższe bezpieczeństwo niż inne DA schematy.

  • Koszt przechowywania: Czynnikiem mającym największy wpływ na koszt przechowywania jest ilość nadmiarowych danych. W krótkoterminowym schemacie przechowywania głównego łańcucha DA, który wykorzystuje do przechowywania formę synchronizacji danych węzła w całej sieci, wszelkie nowo przechowywane dane muszą zostać zarchiwizowane w węzłach w całej sieci, co wiąże się z najwyższym kosztem przechowywania. Wysoki koszt magazynowania powoduje z kolei, że w sieci o wysokim TPS takie podejście nadaje się jedynie do tymczasowego magazynowania. Następna jest metoda przechowywania poprzez sharding, w tym sharding w głównym łańcuchu i sharding w zewnętrznym DA. Ponieważ łańcuch główny często ma więcej węzłów, a zatem odpowiedni blok będzie miał więcej kopii zapasowych, schemat podziału na fragmenty łańcucha głównego będzie miał wyższy koszt. Najniższy koszt przechowywania występuje w publicznym łańcuchu pamięci DA, w którym zastosowano metodę przechowywania z nagrodą, a ilość nadmiarowych danych w tym schemacie zwykle oscyluje wokół stałej stałej. Jednocześnie publiczny łańcuch pamięci masowej DA wprowadza również mechanizm dynamicznej regulacji, który zachęca węzły do ​​przechowywania mniejszej ilości danych kopii zapasowych, zwiększając nagrodę w celu zapewnienia bezpieczeństwa danych.

  • Szybkość odczytu danych: Na szybkość przechowywania danych wpływa przede wszystkim miejsce przechowywania danych w przestrzeni dyskowej, ścieżka indeksu danych oraz dystrybucja danych pomiędzy węzłami. Wśród nich większy wpływ na prędkość ma miejsce przechowywania danych w węzłach, ponieważ przechowywanie danych w pamięci lub na dysku SSD może prowadzić do kilkudziesięciokrotnej różnicy w szybkości odczytu. Dostawcy DA w publicznym łańcuchu pamięci masowej korzystają głównie z pamięci SSD, ponieważ obciążenie tego łańcucha obejmuje nie tylko dane z warstwy DA, ale także dane osobowe wymagające dużej ilości pamięci, takie jak filmy i obrazy przesyłane przez użytkowników. Jeśli sieć nie wykorzystuje dysków SSD jako przestrzeni dyskowej, trudno jest unieść ogromne obciążenie pamięcią masową i zaspokoić zapotrzebowanie na pamięć długoterminową. Po drugie, w przypadku zewnętrznych DA i DA głównego łańcucha, którzy wykorzystują stan pamięci do przechowywania danych, zewnętrzni DA muszą najpierw wyszukać odpowiednie indeksowane dane w głównym łańcuchu, a następnie przesłać zindeksowane dane w całym łańcuchu do trzeciej DA stron i zwrócić dane za pośrednictwem mostu pamięci masowej. W przeciwieństwie do tego główny DA może wysyłać zapytania o dane bezpośrednio z węzłów, dzięki czemu ma większą prędkość pobierania danych. Wreszcie, w ramach głównego łańcucha DA, podejście oparte na fragmentowaniu wymaga wywoływania bloków z wielu węzłów i przywracania oryginalnych danych. Dlatego jest wolniejsza niż metoda krótkotrwałego przechowywania bez fragmentowania.

  • Uniwersalność warstwy DA: Uniwersalność DA Mainchain jest bliska zeru, ponieważ nie jest możliwe przesłanie danych z łańcucha publicznego o niewystarczającej przestrzeni dyskowej do innego łańcucha publicznego o niewystarczającej przestrzeni dyskowej. W zewnętrznych DA ogólność rozwiązania i jego zgodność z konkretnym łańcuchem głównym są metrykami sprzecznymi. Na przykład w przypadku rozwiązania DA specyficznego dla łańcucha głównego, zaprojektowanego dla konkretnego łańcucha głównego, wprowadzono wiele ulepszeń na poziomie typów węzłów i konsensusu sieci, aby dostosować się do tego konkretnego łańcucha publicznego, a zatem te ulepszenia mogą działać jako ogromną przeszkodą w komunikacji z innymi sieciami publicznymi. W przypadku zewnętrznych dostawców danych DA w łańcuchu publicznym pamięci masowej działają lepiej pod względem możliwości uogólnienia niż modułowe DA. Dostawcy DA publicznych łańcuchów pamięci masowej mają większą społeczność programistów i więcej możliwości rozbudowy, aby dostosować się do różnych łańcuchów publicznych. Jednocześnie DA publicznego łańcucha pamięci masowej może aktywniej uzyskiwać dane poprzez przechwytywanie pakietów, zamiast pasywnie odbierać informacje przesyłane z innych łańcuchów publicznych. Dlatego może kodować dane na swój sposób, osiągać ustandaryzowane przechowywanie przepływu danych, ułatwiać zarządzanie informacjami o danych z różnych głównych łańcuchów i poprawiać wydajność przechowywania.

Źródło: Kernel Ventures

6. Wniosek

Blockchain przechodzi proces konwersji z Crypto na Web3, co niesie ze sobą mnóstwo projektów na blockchainie, ale także problemy z przechowywaniem danych. Aby umożliwić jednoczesne działanie tak wielu projektów na warstwie 1 i zapewnić doświadczenie projektów Gamefi i Socialfi, warstwa 1 reprezentowana przez Ethereum przyjęła Rollup i Blobs w celu ulepszenia TPS. Co więcej, liczba wysokowydajnych łańcuchów bloków w nowonarodzonym łańcuchu bloków również rośnie. Jednak wyższy TPS oznacza nie tylko wyższą wydajność, ale także większe obciążenie pamięci w sieci. W przypadku ogromnej ilości danych historycznych na tym etapie proponuje się wiele podejść DA, zarówno w oparciu o łańcuch główny, jak i strony trzecie, aby dostosować się do wzrostu presji magazynowania na łańcuch. Ulepszenia mają swoje zalety i wady oraz mają różne zastosowanie w różnych kontekstach. W przypadku blockchainów płatniczych, które mają bardzo wysokie wymagania co do bezpieczeństwa danych historycznych i nie dążą do szczególnie wysokiego TPS, a które są jeszcze w fazie przygotowawczej, mogą przyjąć metodę przechowywania przypominającą DankSharding, która może zapewnić bezpieczeństwo i jednocześnie ogromny wzrost pojemności magazynowej. Jeśli jednak jest to łańcuch publiczny typu Bitcoin, który już powstał i ma dużą liczbę węzłów, istnieje ogromne ryzyko pochopnego ulepszania warstwy konsensusu, aby mógł przyjąć specjalne DA dla łańcucha głównego z większym bezpieczeństwem w pamięci masowej poza łańcuchem, aby zrównoważyć kwestie bezpieczeństwa i przechowywania. Warto jednak zauważyć, że funkcja blockchainu zmienia się w czasie. Na przykład na początku funkcjonalność Ethereum ograniczała się do płatności i prostego zautomatyzowanego przetwarzania aktywów i transakcji przy użyciu inteligentnych kontraktów, ale wraz z rozwojem krajobrazu blockchain do Ethereum dodano różne projekty Socialfi i Defi, spychając go na bardziej wszechstronny kierunek. Wraz z niedawną eksplozją ekosystemu napisów na Bitcoinie, opłaty transakcyjne w sieci Bitcoin wzrosły od sierpnia prawie 20-krotnie, co odzwierciedla fakt, że prędkość transakcji w sieci nie jest w stanie zaspokoić popytu na transakcje na tym etapie. Traderzy muszą podnieść opłaty, aby transakcje mogły zostać przetworzone tak szybko, jak to możliwe. Teraz społeczność Bitcoin musi dokonać kompromisu pomiędzy akceptowaniem wysokich opłat i niską szybkością transakcji lub zmniejszeniem bezpieczeństwa sieci w celu zwiększenia prędkości transakcji, a przede wszystkim pokonać cel systemu płatności. Jeśli społeczność Bitcoin wybierze to drugie, rozwiązanie do przechowywania danych będzie musiało zostać dostosowane w obliczu rosnącej presji danych.

Source: OKLINK

Jeśli chodzi o sieć publiczną o kompleksowych funkcjach, jej dążenie do TPS jest większe, przy ogromnym wzroście danych historycznych, trudno jest w dłuższej perspektywie dostosować się do szybkiego rozwoju TPS, przyjmując rozwiązanie na wzór DankSharding. Dlatego bardziej odpowiednią metodą jest migracja danych do zewnętrznego DA w celu ich przechowywania. Wśród nich DA specyficzne dla łańcucha głównego mają najwyższą kompatybilność i mogą być bardziej korzystne, jeśli uwzględni się tylko przechowywanie pojedynczego łańcucha publicznego. Jednak obecnie, gdy łańcuchy publiczne warstwy 1 rozkwitają, transfer zasobów między łańcuchami i interakcja danych również stały się powszechnym zajęciem społeczności blockchain. Jeśli weźmiemy pod uwagę długoterminowy rozwój całego ekosystemu blockchain, przechowywanie danych historycznych 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 walidacji danych, dlatego modułowy DA i sposób przechowywania publicznych łańcuchowe DA mogą być lepszym wyborem. Przy założeniu bliskiej ogólności modułowy DA koncentruje się na świadczeniu usług warstwy DA blockchain, wprowadza bardziej wyrafinowane dane indeksowe do zarządzania danymi historycznymi i może dokonać rozsądnej kategoryzacji różnych danych łańcucha publicznego, co ma więcej zalet w porównaniu z publicznymi łańcuchami pamięci masowej. Powyższa propozycja nie uwzględnia jednak kosztów dostosowania warstwy konsensusu w istniejącym łańcuchu publicznym, co jest niezwykle ryzykowne. Mała luka systemowa może sprawić, że łańcuch publiczny straci konsensus społeczności. Dlatego jeśli jest to rozwiązanie przejściowe w procesie transformacji blockchaina, bardziej odpowiednie może okazać się tymczasowe przechowywanie na głównym łańcuchu. Wreszcie, wszystkie powyższe dyskusje opierają się na wynikach podczas faktycznej eksploatacji, ale jeśli celem określonego łańcucha publicznego jest rozwój jego ekologii i przyciągnięcie większej liczby stron i uczestników projektu, może on również faworyzować projekty wspierane i finansowane przez jego fundament. Na przykład, jeśli ogólna wydajność jest równa lub nawet nieco niższa niż w przypadku rozwiązania pamięci masowej w łańcuchu publicznym, społeczność Ethereum będzie również faworyzować EthStorage, który jest projektem warstwy 2 wspieranym przez Fundację Ethereum, aby kontynuować rozwój ekosystemu Ethereum .

Podsumowując, rosnąca złożoność dzisiejszych łańcuchów bloków niesie ze sobą większe zapotrzebowanie na przestrzeń magazynową. Przy wystarczającej liczbie węzłów walidacyjnych warstwy 1 nie trzeba tworzyć kopii zapasowych danych historycznych we wszystkich węzłach w całej sieci, ale mogą one zapewnić bezpieczeństwo po osiągnięciu pewnego progu. Jednocześnie podział pracy łańcucha publicznego staje się coraz bardziej szczegółowy, za konsensus i wykonanie odpowiada warstwa 1, za obliczenia i weryfikację odpowiada Rollup, a następnie do przechowywania danych wykorzystywany jest odrębny blockchain. Każda część może skupiać się na określonej funkcji, nie ograniczając się wydajnością pozostałych części. Jednak konkretna liczba miejsc przechowywania lub proporcja węzłów, które mogą przechowywać dane historyczne w celu osiągnięcia równowagi między bezpieczeństwem a wydajnością, a także sposób zapewnienia bezpiecznej interoperacyjności pomiędzy różnymi blockchainami, to problem, który muszą wziąć pod uwagę twórcy blockchain. Inwestorzy mogą zwrócić uwagę na główny, specyficzny dla łańcucha projekt DA na Ethereum, ponieważ Ethereum ma już na tym etapie wystarczającą liczbę zwolenników, bez konieczności wykorzystywania siły innych społeczności do rozszerzania swoich wpływów. Ważniejsze jest ulepszanie i rozwijanie swojej społeczności, aby przyciągnąć więcej projektów do ekosystemu Ethereum. Jednak w przypadku nadrabiających zaległości sieci publicznych, takich jak Solana i Aptos, pojedyncza sieć sama w sobie nie ma tak doskonałego ekosystemu, dlatego mogą preferować połączenie sił z innymi społecznościami, aby zbudować duży ekosystem międzyłańcuchowy w celu rozszerzenia swoich wpływów . Dlatego w przypadku powstającej warstwy 1 na większą uwagę zasługuje zewnętrzny DA ogólnego przeznaczenia.

Kernel Ventures to fundusz VC działający na rzecz społeczności badawczo-programistycznej, posiadający ponad 70 inwestycji na wczesnym etapie, skupiający się na infrastrukturze, oprogramowaniu pośrednim, dAppach, zwłaszcza ZK, Rollup, DEX, Modular Blockchain i branżach, które wdrożą kolejny miliard użytkowników w branży kryptowalut takie jak abstrakcja kont, dostępność danych, skalowalność itp. Przez ostatnie siedem lat angażowaliśmy się we wspieranie rozwoju głównych społeczności programistów i uniwersyteckich stowarzyszeń Blockchain na całym świecie.

Odniesienie

  1. Celestia: Gwiaździste morze modułowego blockchainu: 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. Ogłaszamy 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. Verkle drzew[J]. Verkle Trees, 2019, 1:1.: https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

  8. Sieć Arweave: https://www.arweave.org/

  9. Żółta księga Arweave: https://www.arweave.org/yellow-paper.pdf