Skalowanie łańcuchów bloków z danymi spoza łańcucha

Opublikowane ponownie przez Plato

Obserwuje: 0

Kiedy hash jest wart miliona słów

Obecnie jest jasne, że wiele przypadków użycia blockchain nie ma nic wspólnego z transakcjami finansowymi. Zamiast tego celem łańcucha jest umożliwienie zdecentralizowanej agregacji, porządkowania, oznaczania czasu i archiwizacji każdy rodzaj informacji, w tym ustrukturyzowane dane, korespondencja lub dokumentacja. Podstawową wartością blockchain jest umożliwienie jego uczestnikom udowodnienia i trwałego ustalenia, jakie dokładnie dane zostały wprowadzone, kiedy i przez kogo, bez polegania na zaufanym pośredniku. Na przykład niedawno uruchomiony SAP platforma blockchain, który obsługuje rozwiązania MultiChain i Hyperledger Fabric, jest przeznaczony dla szerokiego zakresu łańcuchów dostaw i innych zastosowań niefinansowych.

Najprostszym sposobem wykorzystania łańcucha bloków do rejestrowania danych jest osadzenie każdego elementu danych bezpośrednio w transakcji. Każda transakcja w łańcuchu bloków jest podpisywana cyfrowo przez jedną lub więcej stron, replikowana w każdym węźle, porządkowana i oznaczana czasem przez algorytm konsensusu łańcucha oraz przechowywana na stałe w sposób zabezpieczony przed manipulacją. Wszelkie dane w ramach transakcji będą zatem przechowywane identycznie, ale niezależnie przez każdy węzeł, wraz z dowodem na to, kto je napisał i kiedy. Użytkownicy sieci mogą w każdej chwili odzyskać te informacje.

Na przykład MultiChain 1.0 umożliwił utworzenie jednego lub więcej nazwanych „strumieni” w łańcuchu bloków, a następnie wykorzystanie ich do przechowywania i pobierania surowych danych. Każdy strumień ma swój własny zestaw uprawnień do zapisu, a każdy węzeł może dowolnie wybierać strumienie, które chcesz subskrybować. Jeśli węzeł subskrybuje strumień, indeksuje zawartość tego strumienia w czasie rzeczywistym, umożliwiając szybkie pobieranie elementów na podstawie ich kolejności, sygnatury czasowej, numeru bloku lub adresu wydawcy, a także za pomocą „klucza” (lub etykiety) za pomocą których można oznaczyć elementy. MultiChain 2.0 (od wersji alfa 1) rozszerzone strumienie obsługujące tekst Unicode lub dane JSON, a także wiele kluczy na element i wiele elementów na transakcję. Dodano także funkcje podsumowania, takie jak „scalanie JSON”, które w użyteczny sposób łączą elementy z tym samym kluczem lub wydawcą.

Poufność i skalowalność

Przechowywanie danych bezpośrednio na łańcuchu bloków działa dobrze, ale ma dwie kluczowe wady - poufność i skalowalność. Zacznijmy od poufności, zawartość każdego elementu strumienia jest widoczna dla każdego węzła w łańcuchu, a to niekoniecznie jest pożądanym wynikiem. W wielu przypadkach część danych powinna być widoczna tylko dla określonego podzbioru węzłów, nawet jeśli inne węzły są potrzebne do ich uporządkowania, oznaczenia czasu i notarialnego poświadczenia.

Poufność to stosunkowo łatwy problem do rozwiązania poprzez szyfrowanie informacji, zanim zostaną one osadzone w transakcji. Klucz deszyfrujący dla każdego fragmentu danych jest udostępniany tylko tym uczestnikom, którzy mają go zobaczyć. Dostarczanie kluczy może być realizowane w łańcuchu przy użyciu kryptografii asymetrycznej (jako opisane tutaj) lub przez jakiś mechanizm poza łańcuchem, jak jest to preferowane. Każdy węzeł, któremu brakuje klucza do odszyfrowania elementu, nie zobaczy nic poza binarnym bełkotem.

Z drugiej strony skalowalność jest większym wyzwaniem. Powiedzmy, że każda przyzwoita platforma blockchain powinna obsługiwać przepustowość sieci na poziomie 500 transakcji na sekundę. Jeśli celem łańcucha jest przechowywanie informacji, to rozmiar każdej transakcji będzie zależał przede wszystkim od ilości zawartych w niej danych. Każda transakcja będzie również potrzebować (co najmniej) 100 bajtów narzutu na przechowywanie adresu nadawcy, podpisu cyfrowego i kilku innych bitów i części.

Jeśli weźmiemy łatwy przypadek, w którym każdy element jest małą strukturą JSON o wielkości 100 bajtów, całkowita przepustowość danych wyniosłaby 100 kilobajtów na sekundę, licząc z 500 × (100 + 100). Przekłada się to na mniej niż 1 megabit na sekundę przepustowości, co wygodnie mieści się w przepustowości każdego nowoczesnego łącza internetowego. Dane byłyby gromadzone w tempie około 3 terabajtów rocznie, co jest niemałą ilością. Ale teraz z dyskami twardymi o pojemności 12 terabajtów powszechnie dostępne, RAID kontrolery, które łączą wiele dysków fizycznych w jeden logiczny, moglibyśmy z łatwością przechowywać dane z 10-20 lat w każdym węźle bez większych kłopotów i kosztów.

Jednak sytuacja wygląda zupełnie inaczej, jeśli przechowujemy większe informacje, takie jak zeskanowana dokumentacja. Rozsądnej jakości skan JPEG arkusza papieru A4 może mieć rozmiar 500 kilobajtów. Pomnóż to przez 500 transakcji na sekundę i oczekujemy przepustowości 250 megabajtów na sekundę. Przekłada się to na przepustowość 2 gigabitów na sekundę, która jest szybsza niż większość sieci lokalnych, nie mówiąc już o połączeniach z Internetem. Najtańsze w Amazon Web Services opublikowana cena 0.05 USD za gigabajt, oznacza to roczny rachunek za przepustowość w wysokości 400,000 8000 USD na węzeł. A gdzie każdy węzeł będzie przechowywać XNUMX terabajtów nowych danych generowanych rocznie?

Oczywiste jest, że w przypadku aplikacji typu blockchain przechowujących wiele dużych fragmentów danych proste przechowywanie w łańcuchu nie jest praktycznym wyborem. Co więcej, jeśli dane są szyfrowane w celu rozwiązania problemu poufności, węzły są proszone o przechowywanie ogromnej ilości informacji, których nawet nie mogą odczytać. Nie jest to atrakcyjna propozycja dla uczestników sieci.

Rozwiązanie haszujące

Jak więc rozwiązać problem skalowalności danych? Jak możemy wykorzystać zdecentralizowaną notarialność danych w łańcuchu bloków, bez replikowania tych danych do każdego węzła w łańcuchu?

Odpowiedzią jest sprytna technologia zwana „hashem”. Hash to długa liczba (na przykład 256 bitów lub około 80 cyfr dziesiętnych), która jednoznacznie identyfikuje fragment danych. Skrót jest obliczany na podstawie danych przy użyciu pliku funkcja jednokierunkowa który ma ważną właściwość kryptograficzną: biorąc pod uwagę dowolne dane, można łatwo i szybko obliczyć ich hash. Ale biorąc pod uwagę konkretny hash, nie jest możliwe obliczeniowo znalezienie fragmentu danych, który wygenerowałby ten hash. A kiedy mówimy „niewykonalne obliczeniowo”, mamy na myśli więcej obliczeń niż atomów w znanym wszechświecie.

Hashe odgrywają kluczową rolę we wszystkich łańcuchach bloków, ponieważ jednoznacznie identyfikują transakcje i bloki. Stanowią również podstawę wyzwania obliczeniowego w systemach proof-of-work, takich jak bitcoin. Opracowano wiele różnych funkcji skrótu, z nazwami gobbledygook, takimi jak BLAKE2, MD5 i RIPEMD160. Aby jednak jakakolwiek funkcja skrótu była godna zaufania, musi przejść obszerny przegląd akademicki i testy. Testy te mają postać prób ataków, takich jak „preimage” (znajdowanie danych wejściowych z danym hashem), „second preimage” (znajdowanie drugiego wejścia z tym samym hashem co dane wejście) i „collision” (znajdowanie dowolnego dwa różne wejścia z tym samym hashem). Przetrwanie tej rękawicy nie jest łatwe, a długa i tragiczna historia zepsutych funkcji skrótu potwierdza słynną maksymę: „Nie rzucaj własnym krypto”.

Wracając do naszego pierwotnego problemu, możemy rozwiązać problem skalowalności danych w łańcuchach bloków, osadzając skróty dużych fragmentów danych w transakcjach zamiast w samych danych. Każdy hash działa jako „zobowiązanie” do swoich danych wejściowych, a same dane są przechowywane poza łańcuchem bloków lub „poza łańcuchem”. Na przykład, używając popularnej funkcji skrótu SHA256, obraz JPEG o rozmiarze 500 kilobajtów można przedstawić za pomocą 32-bajtowej liczby, co oznacza redukcję o ponad 15,000 500 ×. Nawet przy szybkości XNUMX obrazów na sekundę, daje nam to wygodną pozycję z powrotem na terytorium możliwej przepustowości i wymagań dotyczących pamięci masowej, jeśli chodzi o dane przechowywane w samym łańcuchu.

Oczywiście każdy uczestnik blockchain, który potrzebuje obrazu poza łańcuchem, nie może odtworzyć go ze swojego hasha. Ale jeśli obraz można pobrać w inny sposób, to hash w łańcuchu służy do potwierdzenia, kto go stworzył i kiedy. Podobnie jak zwykłe dane w łańcuchu, skrót jest osadzony w podpisanej cyfrowo transakcji, która została włączona do łańcucha na podstawie konsensusu. Jeśli plik obrazu wypadnie z nieba, a hash dla tego obrazu pasuje do hasha w łańcuchu bloków, wówczas pochodzenie i znacznik czasu tego obrazu są potwierdzane. Tak więc łańcuch bloków zapewnia dokładnie taką samą wartość pod względem notarialności, jak gdyby obraz został osadzony bezpośrednio w łańcuchu.

Kwestia dostawy

Na razie w porządku. Osadzając hashe w łańcuchu bloków zamiast w oryginalnych danych, mamy łatwe rozwiązanie problemu skalowalności. Niemniej jednak pozostaje jedno kluczowe pytanie:

W jaki sposób dostarczamy oryginalną zawartość poza łańcuchem do tych węzłów, które jej potrzebują, jeśli nie przez sam łańcuch?

To pytanie ma kilka możliwych odpowiedzi, a wiemy, że użytkownicy MultiChain stosują je wszystkie. Jedną z podstawowych metod jest utworzenie scentralizowanego repozytorium na zaufanej stronie, w którym wszystkie dane spoza łańcucha są przesyłane, a następnie pobierane. Ten system mógłby naturalnie wykorzystywać „adresowanie treści”, co oznacza, że skrót każdego elementu danych służy bezpośrednio jako jego identyfikator do pobrania. Jednak, chociaż ta konfiguracja może działać w celu weryfikacji koncepcji, nie ma sensu w przypadku produkcji, ponieważ celem łańcucha bloków jest usunięcie zaufanych pośredników. Nawet jeśli skróty w łańcuchu uniemożliwiają pośrednikowi fałszowanie danych, nadal może usunąć dane lub nie dostarczyć ich niektórym uczestnikom z powodu awarii technicznej lub działań nieuczciwego pracownika.

Bardziej obiecującą możliwością jest komunikacja punkt-punkt, w której węzeł wymagający pewnych danych spoza łańcucha żąda ich bezpośrednio od węzła, który je opublikował. Pozwala to uniknąć polegania na zaufanym pośredniku, ale ma trzy alternatywne niedociągnięcia:

Wymaga mapy adresów blockchain na adresy IP, aby umożliwić konsumentowi niektórych danych bezpośrednią komunikację z ich wydawcą. Blockchain może generalnie uniknąć tego typu statycznej konfiguracji sieci, co może stanowić problem z punktu widzenia przełączania awaryjnego i prywatności.
Jeśli pierwotny węzeł wydawcy opuścił sieć lub jest tymczasowo nieczynny, nikt inny nie może pobrać danych.
Jeśli duża liczba węzłów jest zainteresowana niektórymi danymi, to wydawca zostanie przytłoczony żądaniami. Może to spowodować poważne przeciążenie sieci, spowolnić działanie systemu wydawcy i doprowadzić do długich opóźnień dla osób próbujących odzyskać te dane.

Aby uniknąć tych problemów, najlepiej byłoby użyć pewnego rodzaju zdecentralizowanego mechanizmu dostarczania. Węzły powinny mieć możliwość pobierania potrzebnych danych bez polegania na jakimkolwiek indywidualnym systemie - czy to scentralizowanym repozytorium, czy oryginalnym wydawcy danych. Jeśli wiele stron ma dane, powinny dzielić się ciężarem dostarczenia ich każdemu, kto tego chce. Nikt nie musi ufać pojedynczemu źródłu danych, ponieważ skróty w łańcuchu mogą udowodnić, że dane nie zostały zmodyfikowane. Jeśli złośliwy węzeł dostarczy mi nieprawidłowe dane do skrótu, mogę po prostu odrzucić te dane i spróbować zapytać kogoś innego.

Dla tych, którzy mają doświadczenie z udostępnianie plików peer-to-peer protokoły takie jak Napster, Gnutella czy BitTorrent, to wszystko będzie brzmiało znajomo. Rzeczywiście, wiele podstawowych zasad jest takich samych, ale są dwie kluczowe różnice. Po pierwsze, zakładając, że używamy naszego łańcucha bloków w kontekście przedsiębiorstwa, system działa w zamkniętej grupie uczestników, a nie w całym Internecie. Po drugie, blockchain dodaje zdecentralizowaną strukturę porządkowania, znakowania czasowego i poświadczania notarialnego, umożliwiając wszystkim użytkownikom utrzymanie spójnego i odpornego na manipulacje obrazu tego, co dokładnie się stało, kiedy i przez kogo.

W jaki sposób twórca aplikacji blockchain może osiągnąć zdecentralizowane dostarczanie treści poza łańcuchem? Jedną z powszechnych opcji jest wybranie istniejącej platformy udostępniania plików peer-to-peer, takiej jak zabawnie nazwana InterPlanetary File System (IPFS) i używaj go razem z blockchainem. Każdy uczestnik uruchamia zarówno węzeł blockchain, jak i węzeł IPFS, a niektóre programy pośredniczące są koordynowane między nimi. Podczas publikowania danych poza łańcuchem, to oprogramowanie pośredniczące przechowuje oryginalne dane w IPFS, a następnie tworzy transakcję łańcucha blokowego zawierającą hash tych danych. Aby odzyskać niektóre dane spoza łańcucha, oprogramowanie pośredniczące wyodrębnia skrót z łańcucha bloków, a następnie używa tego skrótu do pobrania zawartości z IPFS. Lokalny węzeł IPFS automatycznie weryfikuje pobraną zawartość pod kątem skrótu, aby upewnić się, że nie została zmieniona.

Chociaż to rozwiązanie jest możliwe, to wszystko jest raczej niezdarne i niewygodne. Po pierwsze, każdy uczestnik musi zainstalować, utrzymywać i aktualizować trzy oddzielne części oprogramowania (węzeł blockchain, węzeł IPFS i oprogramowanie pośredniczące), z których każdy przechowuje swoje dane w oddzielnym miejscu. Po drugie, będą dwie oddzielne sieci peer-to-peer, każda z własną konfiguracją, portami sieciowymi, systemem tożsamości i uprawnieniami (chociaż należy zauważyć, że IPFS nie obsługuje jeszcze zamkniętych sieci). Wreszcie, ścisłe powiązanie IPFS i łańcucha bloków ze sobą spowodowałoby, że oprogramowanie pośredniczące byłoby coraz bardziej złożone. Na przykład, jeśli chcemy, aby dane spoza łańcucha, do których odwołują się niektóre transakcje w łańcuchu bloków, były natychmiast pobierane (z automatycznymi ponowieniami), oprogramowanie pośredniczące musiałoby być stale uruchomione i działało, zachowując swój własny złożony stan. Czy nie byłoby miło, gdyby węzeł blockchain zrobił to wszystko za nas?

Dane poza łańcuchem w MultiChain 2.0

Dziś z przyjemnością udostępniamy trzecia wersja podglądowa (alfa 3) MultiChain 2.0, zw pełni zintegrowanym i bezproblemowym rozwiązaniem dla danych spoza łańcucha. Każda informacja opublikowana w strumieniu może być w zależności od potrzeb w łańcuchu lub poza nim, a MultiChain zajmuje się wszystkim innym.

Naprawdę nie, mamy na myśli wszystko. Jako programista korzystający z technologii MultiChain nie będziesz musiał martwić się o skróty, lokalną pamięć masową, wykrywanie treści, zdecentralizowane dostarczanie lub weryfikację danych. Oto, co dzieje się za kulisami:

Węzeł MultiChain publikujący zapisuje nowe dane w swojej lokalnej pamięci masowej, dzieląc duże elementy na porcje, aby ułatwić ich przetrawienie i dostarczenie.
Transakcja publikowania elementów strumieniowych poza łańcuchem jest tworzona automatycznie, zawierająca skróty fragmentów i rozmiar (y) w bajtach.
Ta transakcja jest podpisywana i transmitowana do sieci, propagowana między węzłami i wprowadzana do łańcucha blokowego w zwykły sposób.
Kiedy węzeł zasubskrybowany do strumienia widzi odniesienie do niektórych danych spoza łańcucha, dodaje skróty fragmentu dla tych danych do swojej kolejki pobierania. (Podczas subskrybowania starego strumienia węzeł umieszcza w kolejce wszystkie wcześniej opublikowane elementy spoza łańcucha do pobrania).
W ramach procesu w tle, jeśli w kolejce pobierania węzła znajdują się fragmenty, zapytania są wysyłane do sieci w celu zlokalizowania tych fragmentów, identyfikowanych przez ich skróty.
Te zapytania o fragmenty są propagowane do innych węzłów w sieci w sposób peer-to-peer (na razie ograniczone do dwóch przeskoków - zobacz szczegóły techniczne poniżej).
Każdy węzeł, który ma dane dotyczące fragmentu, może odpowiedzieć, a ta odpowiedź jest przekazywana do subskrybenta z powrotem tą samą ścieżką, co zapytanie.
Jeśli żaden węzeł nie odpowie na zapytanie o porcję, porcja jest zwracana z powrotem do kolejki w celu późniejszej ponownej próby.
W przeciwnym razie subskrybent wybiera najbardziej obiecujące źródło dla fragmentu (na podstawie przeskoków i czasu odpowiedzi) i wysyła do niego żądanie danych tego fragmentu, ponownie tą samą ścieżką peer-to-peer, co poprzednia odpowiedź.
Węzeł źródłowy dostarcza żądane dane, ponownie używając tej samej ścieżki.
Subskrybent weryfikuje rozmiar i hash danych na podstawie pierwotnego żądania.
Jeśli wszystko się powiedzie, subskrybent zapisuje dane w swojej lokalnej pamięci, udostępniając je natychmiast do pobrania za pośrednictwem strumieniowych interfejsów API.
Jeśli żądana treść nie dotarła lub nie pasuje do żądanego skrótu lub rozmiaru, fragment jest zwracany z powrotem do kolejki w celu przyszłego pobrania z innego źródła.

Co najważniejsze, wszystko to dzieje się niezwykle szybko. W sieciach o małych opóźnieniach małe fragmenty danych spoza łańcucha docierają do abonentów w ciągu ułamka sekundy od transakcji, która się do nich odwołuje. W przypadku aplikacji o dużym obciążeniu nasze testy pokazują, że MultiChain 2.0 alpha 3 może wytrzymać ponad 1000 elementów spoza łańcucha lub 25 MB danych pobieranych poza łańcuchem na sekundę na serwerze średniej klasy (Core i7) z przyzwoitą Połączenie internetowe. Wszystko działa dobrze z elementami poza łańcuchem o rozmiarze do 1 GB, znacznie przekraczając limit 64 MB dla danych w łańcuchu. Oczywiście mamy nadzieję na dalszą poprawę tych liczb, ponieważ poświęcamy czas na optymalizację MultiChain 2.0 w fazie beta.

Korzystając z danych poza łańcuchem zamiast w łańcuchu w strumieniach, programiści aplikacji MultiChain muszą zrobić dokładnie dwie rzeczy:

Publikując dane, należy przekazać flagę „offchain” do odpowiednich interfejsów API.
Korzystając z interfejsów API z zapytaniami strumieniowymi, należy wziąć pod uwagę możliwość, że niektóre dane spoza łańcucha mogą nie być jeszcze dostępne, co sygnalizuje flaga „dostępne”. Chociaż taka sytuacja będzie rzadka w normalnych okolicznościach, ważne jest, aby twórcy aplikacji odpowiednio sobie z nią poradzili.

Oczywiście, aby uniemożliwić każdemu węzłowi pobranie każdego elementu spoza łańcucha, elementy powinny być grupowane w strumienie w odpowiedni sposób, przy czym każdy węzeł subskrybuje te strumienie zainteresowania.

Elementy w łańcuchu i poza łańcuchem mogą być używane w tym samym strumieniu, a różne funkcje zapytań strumieniowych i podsumowania odnoszą się identycznie do obu typów danych. Pozwala to wydawcom na dokonanie odpowiedniego wyboru dla każdego elementu w strumieniu bez wpływu na resztę aplikacji. Na przykład strumień elementów JSON dotyczących działań ludzi może wykorzystywać dane spoza łańcucha do osobistych informacji identyfikacyjnych, a dane w łańcuchu do pozostałych. Subskrybenci mogą używać scalania JSON MultiChain, aby połączyć oba typy informacji w jeden JSON do odczytu.

Jeśli chcesz wypróbować elementy strumieniowe poza łańcuchem, po prostu postępuj zgodnie ze zwykłymi instrukcjami MultiChain Pierwsze kroki samouczek i nie pomijaj sekcji 5.

Więc, co dalej?

Dzięki bezproblemowej obsłudze danych spoza łańcucha, MultiChain 2.0 zaoferuje duży krok naprzód dla aplikacji opartych na łańcuchu bloków, które koncentrują się na znacznikach czasowych i notarialności danych. W dłuższej perspektywie już myślimy o wielu możliwych przyszłych ulepszeniach tej funkcji dla wersji Community i / lub Enterprise MultiChain:

Wdrażanie strumienia czytać uprawnienia przy użyciu kombinacji elementów poza łańcuchem, solonych skrótów, podpisanych zapytań o fragmenty i zaszyfrowanej dostawy.
Umożliwienie jawnego „zapomnienia” danych spoza łańcucha, zarówno dobrowolnie przez poszczególne węzły, jak i przez wszystkie węzły w odpowiedzi na wiadomość w łańcuchu.
Subskrypcje strumienia selektywnego, w których węzły pobierają dane tylko dla elementów spoza łańcucha z określonymi wydawcami lub kluczami.
Korzystanie z drzewa merkle aby umożliwić pojedynczemu hashowi w łańcuchu reprezentowanie nieograniczonej liczby elementów poza łańcuchem, co daje kolejny ogromny skok pod względem skalowalności.
Wtykowe silniki pamięci masowej, umożliwiające przechowywanie danych poza łańcuchem w bazach danych lub zewnętrznych systemach plików zamiast na dysku lokalnym.
Węzły uczą się w czasie, gdy każdy typ danych poza łańcuchem jest zwykle dostępny w sieci i odpowiednio koncentrują swoje zapytania dotyczące fragmentów.

Chcielibyśmy usłyszeć swoją opinię na powyższej liście, a także ogólnie poza łańcuchem. Ponieważ MultiChain 2.0 nadal oficjalnie jest w wersji alfa, jest dużo czasu na ulepszenie tej funkcji przed jej ostateczną premierą.

W międzyczasie rozpoczęliśmy już prace nad „Inteligentnymi filtrami”, ostatnią ważną funkcją zaplanowaną dla społeczności MultiChain 2.0. Inteligentny filtr to fragment kodu osadzony w łańcuchu bloków, który implementuje niestandardowe reguły sprawdzania poprawności danych lub transakcji. Inteligentne filtry mają pewne podobieństwa do „inteligentnych kontraktów” i mogą robić wiele tych samych rzeczy, ale mają kluczowe różnice pod względem bezpieczeństwa i wydajności. Z niecierpliwością czekamy na dalsze informacje w odpowiednim czasie.

Prosimy o umieszczanie komentarzy na LinkedIn.

Szczegóły techniczne

Chociaż elementy strumieniowe poza łańcuchem w MultiChain 2.0 są proste w użyciu, zawierają wiele decyzji projektowych i dodatkowe funkcje, które mogą być interesujące. Poniższa lista będzie odpowiednia głównie dla programistów tworzących aplikacje typu blockchain i można ją pominąć w przypadku mniej technicznych typów:

Zasady dotyczące poszczególnych strumieni. Po utworzeniu strumienia MultiChain można opcjonalnie ograniczyć zezwalanie tylko na dane w łańcuchu lub poza łańcuchem. Jest kilka możliwych powodów, dla których warto to zrobić, zamiast pozwalać każdemu wydawcy samodzielnie decydować. Na przykład produkty w łańcuchu oferują solidną gwarancję dostępności, podczas gdy stare produkty poza łańcuchem mogą stać się nieodwracalne, jeśli ich wydawca i inni subskrybenci zrezygnują z sieci. Z drugiej strony, elementy na łańcuchu nie mogą zostać „zapomniane” bez modyfikacji łańcucha blokowego, podczas gdy elementy poza łańcuchem są bardziej elastyczne. Może to być ważne z punktu widzenia zasad ochrony danych, takich jak nowe europejskie przepisy RODO.
Metadane w łańcuchu. W przypadku pozycji poza łańcuchem transakcja w łańcuchu nadal zawiera wydawców, klucze, format (JSON, tekst lub plik binarny) i całkowity rozmiar. Wszystko to zajmuje bardzo mało miejsca i pomaga programistom aplikacji określić, czy niedostępność elementu spoza łańcucha jest problemem dla konkretnego zapytania strumieniowego.
Limit dwóch przeskoków. Podczas przekazywania zapytań porcji przez sieć peer-to-peer występuje kompromis między osiągalnością a wydajnością. Chociaż byłoby dobrze, gdyby każde zapytanie było propagowane wzdłuż każdej ścieżki, może to spowodować zapchanie sieci niepotrzebnym „paplaniną”. Na razie więc zapytania o fragmenty są ograniczone do dwóch przeskoków, co oznacza, że węzeł może pobierać dane spoza łańcucha od dowolnego peera ze swoich rówieśników. W mniejszych sieciach poniżej 1000 węzłów, które zwykle charakteryzują łańcuchy bloków przedsiębiorstw, uważamy, że będzie to działać dobrze, ale łatwo jest nam dostosować to ograniczenie (lub zaoferować je jako parametr), jeśli okaże się, że się mylimy.
Lokalny magazyn. Każdy węzeł MultiChain przechowuje dane spoza łańcucha w katalogu „chunks” swojego zwykłego katalogu łańcucha bloków, przy użyciu wydajnego formatu binarnego i indeksu LevelDB. Oddzielny podkatalog jest używany dla pozycji w każdym z subskrybowanych strumieni, a także dla tych publikowanych przez sam węzeł. W każdym z tych podkatalogów zduplikowane fragmenty (z tym samym hashem) są przechowywane tylko raz. Gdy węzeł wypisuje się ze strumienia, może zdecydować, czy usunąć dane spoza łańcucha pobrane dla tego strumienia.
Binarna pamięć podręczna. Podczas publikowania dużych fragmentów danych binarnych, zarówno w łańcuchu, jak i poza łańcuchem, programiści aplikacji mogą nie być praktyczni, aby wysyłać te dane do interfejsu API MultiChain w pojedynczym żądaniu JSON-RPC. Dlatego MultiChain 2.0 implementuje binarną pamięć podręczną, która umożliwia tworzenie dużych fragmentów danych w wielu wywołaniach interfejsu API, a następnie publikowanie ich w krótkim ostatnim kroku. Każda pozycja w binarnej pamięci podręcznej jest przechowywana jako prosty plik w podkatalogu „cache” katalogu blockchain, umożliwiając również przesyłanie gigabajtów danych bezpośrednio przez system plików.
Monitorowanie interfejsów API. MultiChain 2.0 alfa 3 dodaje dwa nowe interfejsy API do monitorowania asynchronicznego pobierania danych spoza łańcucha. Pierwszy interfejs API opisuje aktualny stan kolejki, pokazując, ile fragmentów (i ile danych) oczekuje lub jest odpytywanych lub pobieranych. Drugi interfejs API zapewnia statystyki zbiorcze dla wszystkich zapytań i żądań dotyczących porcji wysłanych od momentu uruchomienia węzła, w tym liczby różnych typów awarii.
Opróżnij po opublikowaniu. Podczas publikowania pozycji poza łańcuchem, MultiChain zapewnia, że lokalna kopia danych jest w całości zapisywana (lub „opróżniana”) na fizycznym dysku twardym, zanim transakcja odwołująca się do tych danych zostanie rozesłana do sieci. W przeciwnym razie, jeśli węzeł miał pecha i stracił moc natychmiast po rozgłoszeniu transakcji, dane spoza łańcucha mogą zostać trwale utracone. Nie stanowi to problemu dla samego MultiChain, ponieważ opóźnienia między próbami pobrania fragmentu rosną automatycznie w czasie. Ale może to powodować problemy na poziomie aplikacji, gdzie każdy wie o istnieniu pewnych danych, ale nikt nie jest w stanie ich znaleźć.
Wydajność wydawnicza. Wypłukując w ten sposób dane spoza łańcucha na dysk, MultiChain może spowodować spadek wydajności, ponieważ dyski fizyczne działają wolno. Na przykład dysk twardy o średniej prędkości obrotowej 7200 obr./min może wykonać tylko około 100 losowych zapisów danych na sekundę, ograniczając z kolei szybkość, z jaką pojedynczy węzeł może publikować elementy spoza łańcucha. Istnieją trzy możliwe obejścia tego problemu. Po pierwsze i najprościej, węzły mogą używać dysku urządzenia półprzewodnikowego (SSD) zamiast zwykłego dysku twardego, który obsługuje 10,000 losowych operacji zapisu na sekundę. Po drugie, wiele pozycji poza łańcuchem można opublikować w ramach jednej transakcji za pomocą interfejsu API „createrawsendfrom”. W takim przypadku MultiChain zapisuje wszystkie dane spoza łańcucha, do których odwołuje się transakcja w ramach jednej operacji na dysku. Wreszcie, MultiChain można skonfigurować tak, aby nie spuszczał danych spoza łańcucha na dysk przed rozgłaszaniem transakcji, która się do nich odwołuje. Używaj tej opcji ostrożnie.
Integracja z rodzimą walutą. W przypadkach użycia, które tego wymagają, MultiChain zawsze oferował opcję użycia rodzimej waluty w łańcuchu bloków, aby zapobiec spamowaniu transakcji i / lub zachęcić do weryfikacji bloków („górników”). W takich przypadkach transakcje muszą oferować górnikom minimalną opłatę, która jest proporcjonalna do ich rozmiaru w bajtach, aby mogły zostać przekazane i potwierdzone w łańcuchu. Mechanizm ten został rozszerzony, aby umożliwić zapobieganie spamowi poza łańcuchem, wymagając minimalnej dodatkowej opłaty za kilobajt danych spoza łańcucha, do których odwołuje się transakcja.
Archiwizuj węzły. Jeśli węzeł chce subskrybować każdy strumień, a zatem pobierać i przechowywać każdy opublikowany element spoza łańcucha, można go tak skonfigurować, aby robił to za pomocą parametru wykonawczego „autosubscribe”. Każdy taki węzeł będzie działał jako kopia zapasowa dla całej sieci, gwarantując, że elementy spoza łańcucha nie zostaną utracone ani niedostępne, bez względu na to, które inne węzły znikną. Można sobie wyobrazić firmy zewnętrzne oferujące to jako usługę komercyjną.