Mapa drogowa MultiChain 1.0 beta 2 i 2.0

Gdzie jesteśmy dzisiaj i dokąd zmierzamy jutro

Dziś z przyjemnością udostępniamy drugą wersję beta MultiChain 1.0 dla systemów Linux, Windows i Mac (na razie wersja na Maca wymaga kompilacji). Na tym kończy się planowany rozwój MultiChain 1.0 - z wyjątkiem wszelkich poprawek błędów, ostateczna wersja MultiChain 1.0 w okresie letnim pozostanie niezmieniona.

W tym miesiącu mijają również dwa lata od pierwszej wersji alfa MultiChain w czerwcu 2015 r. Podobnie jak w przypadku każdego nowego produktu, nie byliśmy pewni, jak zareaguje rynek, i wiedzieliśmy, że jest tylko jeden sposób, aby się tego dowiedzieć - wydać minimalny opłacalny produkt, co oznacza wersję początkową, która zapewnia znaczną wartość, ale jest wstępna z założenia. Na szczęście w przeciwieństwie do naszego pierwszego produktu MonetaSparkMultiChain otrzymał silną i natychmiastową pozytywną odpowiedź. Towarzyszyło temu tsunami rozsądnych żądań funkcji, z których wiele już zaimplementowaliśmy. Równolegle z rozwojem produktu, pod każdym względem jego użycie znacznie wzrosło. Na przykład witryna MultiChain odwiedziła mniej niż 3,000 w lipcu 2015 r., A teraz przynosi dziesięciokrotnie więcej miesięcznie.

Wydajność MultiChain

W ciągu ostatnich dwóch lat włożyliśmy wiele wysiłku w optymalizację MultiChain, z którego został rozwidlony Bitcoin Core, implementacja referencyjna dla publicznej sieci bitcoin. Poniżej znajduje się porównanie przepustowości transakcji dla konfiguracji z jednym węzłem przy użyciu pięciu wersji produktu:

.przepustowość td,.przepustowość th {text-align:right;}

Całkowita liczba transakcji	1.0 alfa 3	1.0 alfa 21	1.0 alfa 22	1.0 1 beta	1.0 2 beta
100	6.5 t / s	7.8	541.7	830.6	1465.7
1,000	7.0	7.6	583.9	889.4	1199.6
10,000	4.1	6.4	566.9	746.6	1071.2
100,000	-	6.6	558.0	771.9	1034.2
1,000,000	-	-	548.6	773.6	1055.4

Średnia liczba transakcji na sekundę, w tym narzut API i tworzenie, podpisywanie, wydobywanie i weryfikowanie transakcji i bloków.
Testy wykonane przy użyciu ab Narzędzie do testowania wydajności serwera HTTP wysyłające dwa równoczesne żądania do sendtoaddress API.
Specyfikacje serwera: Intel Core i7-4770, 4 rdzenie @ 3.4 MHz, 32 GB RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Oczywiście największy skok nastąpił w alfa 22, kiedy my przeniesiony do portfela opartego na bazie danych. Ale od tego wydania ponownie prawie podwoiliśmy prędkość MultiChain. Mamy nadzieję, że wykazaliśmy, że ograniczenie bitcoina do 4 transakcji na sekundę wynika z jego szczególnych parametrów sieciowych i nie ma żadnego związku z łańcuchami bloków w ogóle.

Oczywiście optymalizacja wydajności to niekończące się zadanie i nie ma powodu, dla którego MultiChain nie może osiągnąć 10,000 tx / s na 16-rdzeniowy procesor z odpowiednimi zmianami architektonicznymi. Jednak na podstawie rozmów z naszymi użytkownikami i partnerami wydaje się, że niewielu spodziewa się potrzebować więcej niż 1,000 tx / s przez kilka następnych lat. Dlatego ponownie koncentrujemy nasze wysiłki programistyczne na nowych funkcjach, co ładnie przybliża nas do tematu MultiChain 2.0.

Omówienie MultiChain 2.0

Wersja 2.0 MultiChain będzie pierwszą, która pojawi się w dwóch edycjach - Community (open source) i Enterprise (komercyjna). Skoncentruję się tutaj na bezpłatnej edycji Community, ponieważ omawiamy tylko szczegóły MultiChain Enterprise nasi partnerzy. W każdym przypadku wersje Community i Enterprise będą wysoce kompatybilne, pod tym względem: (a) aplikacje zbudowane w wersji Community będą działać bez modyfikacji w MultiChain Enterprise oraz (b) obie wersje będą mogły łączyć się i przeprowadzać między sobą transakcje na tym samym łańcuchu.

Trzy kluczowe obszary zwiększonej funkcjonalności w obu edycjach MultiChain 2.0 to:

• Bogatszy model danych dla strumieni, w tym dokumentów JSON.
• Niestandardowe programowalne filtry transakcji do weryfikacji w łańcuchu.
• Bezproblemowa aktualizacja protokołu i parametrów łańcucha bloków.

Przejdźmy do szczegółowego omówienia każdego z nich.

Bogatszy model danych dla strumieni

Strumienie MultiChain zostały wprowadzone we wrześniu 2016 roku i okazały się niezwykle popularne. Jak opisano w ten post, strumienie zapewniają prostą i naturalną abstrakcję dla ogólnego przechowywania danych, indeksowania i pobierania w łańcuchu bloków. Blockchain MultiChain może zawierać dowolną liczbę nazwanych strumieni, z których każdy może być otwarty dla wszystkich do zapisu lub zapisywalny tylko z określonych adresów.

W MultiChain 1.0 każdy element strumienia ma jednego lub więcej wydawców (którzy go podpisują), opcjonalny klucz, binarny ładunek danych o rozmiarze do 64 MB i znacznik czasu (pochodzący z bloku, w którym jest osadzony). Każdy węzeł może swobodnie decydować, które strumienie subskrybować, lub może automatycznie subskrybować wszystkie strumienie. Jeśli węzeł subskrybuje strumień, indeksuje zawartość tego strumienia w czasie rzeczywistym, umożliwiając wydajne pobieranie według wydawcy, klucza, bloku, znacznika czasu lub pozycji.

MultiChain 2.0 wzbogaci funkcjonalność tego strumienia na kilka sposobów:

• Elementy JSON. Oprócz danych binarnych elementy strumieniowe będą obsługiwać ustrukturyzowane obiekty JSON, przechowywane w łańcuchu bloków w wydajnym formacie serializacji, takim jak UBJSON. Ponieważ interfejs API MultiChain używa już JSON, te obiekty JSON będą zapisywalne i czytelne w naturalny i oczywisty sposób.
• Wiele kluczy. Elementy strumienia będą obsługiwać wiele kluczy, umożliwiając indeksowanie pojedynczego fragmentu danych na wiele sposobów w celu pobrania za pomocą liststreamkeyitems. Stale oceniamy, ile funkcji bazy danych należy uwzględnić w MultiChain i nie spodziewamy się obsługi indeksowania elementów podrzędnych w elementach strumienia JSON w wersji 2.0. Zezwolenie na wiele kluczy na element strumienia stanowi rozsądne obejście tego problemu.
• Atomowe zapisy wielu elementów. MultiChain 1.0 pozwala pojedynczej transakcji na zapis do wielu strumieni, ale nie na zapis wielu elementów w tym samym strumieniu. MultiChain 2.0 usunie to ograniczenie.
• Scalanie JSON. Każda uporządkowana lista obiektów JSON może być naturalnie spłaszczona lub podsumowana w celu utworzenia „scalonego” obiektu. Scalony obiekt zawiera wszystkie klucze, które pojawiają się w poszczególnych obiektach, gdzie wartość odpowiadająca każdemu kluczowi jest pobierana z ostatniego obiektu, w którym ten klucz się pojawia. Jeśli chcesz, scalony obiekt jest końcowym stanem wiersza bazy danych, którego kolumny są definiowane przez pierwszy obiekt i rozszerzane lub aktualizowane przez późniejsze obiekty. MultiChain 2.0 doda interfejsy API, aby łatwo i szybko pobrać scalony obiekt dla elementów JSON w strumieniu z określonym kluczem lub wydawcą.

Te funkcje pochodzą z typowych sposobów, w jakie programiści obecnie używają strumieni. Innymi słowy, obserwujemy, co wiele osób tworzy w oparciu o MultiChain na poziomie aplikacji i przenosi tę funkcjonalność do samego MultiChaina - wzór, który zamierzamy nadal stosować. Teraz, gdy elementy strumienia będą zawierać informacje o typie, można je łatwo rozszerzyć w przyszłości, aby obsługiwały inne formaty danych, takie jak XML, HDF5 i MIM-identyfikowana treść. Nie wspominając o możliwościach przezroczystej kompresji i szyfrowania w łańcuchu.

MultiChain 2.0 będzie również obsługiwał obiekty JSON dla surowych metadanych transakcji (tj. Nie elementów strumieniowych), a także metadane dla zdarzeń wydawania aktywów i tworzenia strumienia, zamiast tekstowych par klucz / wartość zaimplementowanych w MultiChain 1.0. Plik listassets API będzie oferować łączenie JSON we wszystkich zdarzeniach emisji zasobu, dzięki czemu metadane każdej emisji mogą skutecznie aktualizować ostateczny opis zasobu.

Niestandardowe filtry transakcji

Dużo myśleliśmy o tym, jak dodać niestandardowe programowalne reguły do ​​MultiChain. Chociaż paradygmat „inteligentnego kontraktu” Ethereum jest popularny, ma on wiele kluczowych niedociągnięć w przypadku łańcuchów bloków o dużej przepustowości, na które zezwolono. Po pierwsze, inteligentne kontrakty wprowadzają globalną zależność w całym stanie łańcucha bloków, co drastycznie pogarsza współbieżność i wydajność. Po drugie, inteligentne kontrakty nie mogą powstrzymać nieprawidłowych transakcji przed osadzeniem w łańcuchu bloków, a jedynie uniemożliwiają tym transakcjom aktualizację stanu bazy danych łańcucha bloków. Chociaż w dłuższej perspektywie spodziewamy się, że maszyna wirtualna kompatybilna z Ethereum będzie oferowana jako abstrakcja wysokiego poziomu w ramach MultiChain, nie uważamy, że jest to właściwe rozwiązanie do walidacji niskiego poziomu.

MultiChain 2.0 wprowadzi inny paradygmat zwany filtrami transakcji, który weryfikuje poszczególne transakcje bez odniesienia do jakiegokolwiek stanu globalnego. Oczekujemy, że filtry będą pisane w języku JavaScript i wykonywane w ramach wbudowanego silnika wykonawczego, takiego jak v8, który jest używany w Google Chrom przeglądarka i node.js Platforma. Oczywiście musimy upewnić się, że kod filtru działa identycznie w każdym węźle w łańcuchu bloków, blokując każdy źródła niedeterminizmu takie jak odczytywanie godziny, używanie liczb losowych, uzyskiwanie dostępu do sieci lub dysku lub wykonywanie operacji matematycznych zależnych od architektury serwera hosta. Stworzenie deterministycznego środowiska uruchomieniowego Javascript jest wyzwaniem, ale (nie zdradzając zbyt wiele) uważamy, że w przyszłości będzie przydatne dla kilku innych funkcji MultiChain.

Do filtrów zostanie przekazany obiekt JSON opisujący pojedynczą transakcję o strukturze podobnej do danych wyjściowych decoderawtransaction ale z dodatkowymi polami. Na przykład każda transakcja wejściowa w formacie JSON będzie zawierać strukturę opisującą poprzednie dane wyjściowe transakcji, które wydała, a każdemu adresowi będzie towarzyszyć lista uprawnień aktualnie posiadanych przez ten adres. Zadaniem filtru jest zwrócenie wartości logicznej wskazującej, czy transakcja jest akceptowalna, a jeśli nie, podanie błędu tekstowego wyjaśniającego dlaczego. Interfejs API MultiChain będzie zawierał polecenia do tworzenia filtrów, testowania ich na poprzednich lub nowych transakcjach i aktywowania ich na podstawie zgody administratora.

W przeciwieństwie do kontraktów inteligentnych, jeśli w kodzie filtru zostanie wykryty błąd, można go łatwo zastąpić nową wersją. Niemniej jednak, podobnie jak cały kod kompletny w Turingu, filtry nadal niosą ze sobą ryzyko wprowadzenia nieskończonej pętli. Ten problem zostanie złagodzony na dwa sposoby:

• Filtry mogą być instalowane i aktywowane tylko przez administratorów sieci, za zgodą. Daje to każdemu administratorowi możliwość dogłębnego zbadania kodu filtru przed zagłosowaniem na jego aktywację.
• Wszystkie dobrze działające węzły będą sprawdzać nowe transakcje przy użyciu aktywnych filtrów przed przekazaniem ich do węzłów równorzędnych. W rezultacie, jeśli transakcja wysyła filtr do nieskończonej pętli, transakcja nie powinna rozprzestrzeniać się poza węzeł, który ją utworzył.

Oczekujemy, że jedna popularna aplikacja dla filtrów będzie sprawdzać poprawność elementów strumienia. Na przykład filtr może zapewnić, że określone pola w elementach JSON strumienia zawierają liczby z określonego zakresu. W MultiChain 1.0 tego typu walidacja musi być wykonywana na poziomie aplikacji, albo podczas pisania elementów strumienia (jeśli źródło jest zaufane), albo podczas ich odczytu. Z kolei MultiChain 2.0 umożliwi osadzenie tych reguł w samym łańcuchu bloków, podobnie jak sprawdź ograniczenia w relacyjnej bazie danych.

MultiChain 2.0 będzie zawierał dwie dodatkowe funkcje, dzięki którym filtry będą jeszcze bardziej wydajne. Najpierw wprowadzi uprawnienia zdefiniowane przez użytkownika, które istnieją obok ośmiu uprawnień zdefiniowanych przez MultiChain. Podobnie jak w przypadku zwykłych uprawnień, będą one nadawane określonym adresom przez administratorów (aw niektórych przypadkach przez użytkowników z rozszerzeniem activate uprawnienia) i dołączane wraz z adresami w obiekcie JSON przekazanym do filtra. Na przykład filtr mógłby zapewnić, że tylko adresy z określonymi uprawnieniami zdefiniowanymi przez użytkownika mogą zapisywać określone typy danych w strumieniu lub przeprowadzać transakcje dotyczące określonego zasobu powyżej określonego progu.

Po drugie, MultiChain 2.0 będzie obsługiwał niestandardowe (binarne lub JSON) metadane w ramach zwykłych danych wyjściowych transakcji. Dzięki temu dane wyjściowe będą działały jako ogólny wiersz bazy danych „będący własnością” adresu wewnątrz. Filtry zobaczą wszystkie metadane w wydanych i utworzonych wynikach transakcji jako część jej opisu JSON. W rezultacie MultiChain stanie się uniwersalnym mechanizmem współdzielonej bazy danych, w którym ważność transakcji jest określana przez konfigurowalną funkcję tworzonych i usuwanych wierszy. (Jeśli brzmi to trochę abstrakcyjnie, z pewnością przedstawimy kilka konkretnych przykładów).

Aktualizacja Blockchain

Ponieważ łańcuchy bloków są zaprojektowane tak, aby działały przez wiele lat, ich charakterystyka może wymagać zmiany w czasie. Obecna wersja MultiChain zapewnia już spory stopień elastyczności, umożliwiając zmianę uprawnień (w tym administratorów i górników w drodze konsensusu), tworzenie nowych zasobów i strumieni oraz bezproblemowe dodawanie lub usuwanie węzłów z sieci. Niemniej jednak w MultiChain 1.0 podstawowy łańcuch bloków parametry, takie jak maksymalny rozmiar bloku i docelowy czas potwierdzenia, są ustalane podczas tworzenia łańcucha i nie można ich później zmienić.

MultiChain 2.0 doda możliwość aktualizacji łańcucha bloków, umożliwiając modyfikację wielu (ale nie wszystkich) jego parametrów, podczas gdy łańcuch nadal działa. Podobnie jak inne ważne operacje, aktualizacja łańcucha bloków będzie wymagać dostosowywalnego poziomu konsensusu administratora, gdzie sam ten poziom jest parametrem, który można zmienić. Aktualizacje zaczną obowiązywać od określonego bloku i będą obowiązywać w każdym kolejnym bloku aż do następnej aktualizacji.

Parametry łańcucha bloków, które można aktualizować, obejmują:

• Wersja protokołu. Umożliwi to uaktualnienie łańcucha bloków utworzonego za pomocą jednej wersji MultiChain w celu obsługi funkcji w nowej wersji, takich jak elementy strumieniowe JSON lub filtry transakcji. Rzeczywiście, wersja protokołu 10008 wprowadzona w MultiChain 1.0 alpha 29 (i używana w wersji beta) została już zabezpieczona w przyszłości z nieudokumentowaną obsługą tego typu aktualizacji. Gdy łańcuch bloków MultiChain 1.0 zostanie zaktualizowany do protokołu 2.0, uzyska również dostęp do innych opisanych tutaj zmian parametrów.
• Skalowanie Blockchain. Popularność łańcuchów bloków może przekroczyć początkowe wartości ustalone dla docelowego czasu potwierdzenia lub maksymalnych rozmiarów transakcji i bloków. MultiChain 2.0 pozwoli w razie potrzeby zwiększyć lub zmniejszyć te wartości.
• Model uprawnień. MultiChain 2.0 pozwoli na aktualizację wielu parametrów związanych z zezwoleniami i zarządzaniem, w tym: (a) anyone-can-* parametry, które kontrolują sposoby, w jakie blockchain jest otwarty lub zamknięty, (b) admin-consensus-* parametry określające poziomy konsensusu administratora wymagane dla niektórych operacji oraz (c) mining-diversity parametr, który kontroluje ścisłość algorytmu konsensusu okrężnego.

Po wdrożeniu tej funkcji aktualizacji nie powinno być powodu, dla którego łańcuch bloków utworzony w MultiChain nie mógłby działać przez wiele dziesięcioleci lub dłużej.

Patrząc przed siebie

Rozpoczęliśmy już pracę nad MultiChain 2.0 i czekamy na realizację tego planu. Bez wątpienia zostaną uwzględnione również inne ulepszenia. Podobnie jak w przypadku MultiChain 1.0, po drodze będziemy mieć wydania alfa, aby programiści mogli używać i uczyć się nowych funkcji w miarę ich wdrażania (i oczywiście zgłaszać wszelkie problemy lub niedociągnięcia). Oczywiście przez cały ten okres będziemy nadal utrzymywać wersję 1.0, naprawiając wszelkie pojawiające się błędy.

Na zakończenie chciałbym podziękować naszemu zespołowi ds. Rozwoju, kierowanemu przez dr. Michaela Rozantseva, za ich nieustającą doskonałość i ciężką pracę. Postrzegamy MultiChain jako prosty projekt inżynierii oprogramowania, w którym jakość kodu i testowanie liczą się przede wszystkim. Mam przywilej pracować z ludźmi, którzy potrafią przekształcić złożoną wizję produktu w stabilne działające oprogramowanie o tak niezwykłej wydajności i szybkości.

Prosimy o umieszczanie komentarzy na LinkedIn.