Cztery oryginalne przypadki użycia blockchain

Gdzie współdzielone księgi dodają rzeczywistą wartość w IT przedsiębiorstwa

Prawie rok po pierwszym wydaniu MultiChain, dowiedzieliśmy się bardzo dużo o tym, jak łańcuchy bloków, w sensie prywatnym i nie kryptowalutowym, mogą i nie mogą być stosowane do problemów w świecie rzeczywistym. Pozwólcie, że podzielę się tym, co wiemy do tej pory.

Po pierwsze, pierwsza myśl, od której my (i wielu innych) zaczęliśmy, wydaje się być błędna. Pomysł ten, zainspirowany bezpośrednio przez bitcoin, polegał na tym, że prywatne łańcuchy bloków (lub „wspólne księgi”) można wykorzystać do bezpośredniego rozliczania większości transakcji płatniczych i wymiany w sektorze finansowym, używając tokenów łańcuchowych do reprezentowania gotówki, akcji, obligacji i więcej.

Jest to całkowicie wykonalne na poziomie technicznym, więc w czym problem? Jednym słowem, poufność. Jeśli wiele instytucji korzysta ze wspólnej księgi, to każda instytucja widzi każdą transakcję w tej księdze, nawet jeśli nie od razu zna rzeczywistą tożsamość zaangażowanych stron. Okazuje się, że jest to ogromny problem, zarówno pod względem regulacji, jak i realiów handlowych konkurencji międzybankowej. Chociaż dostępne są lub są opracowywane różne strategie łagodzenia tego problemu, żadna nie jest w stanie dorównać prostocie i wydajności scentralizowanej bazy danych zarządzanej przez zaufanego pośrednika, który zachowuje pełną kontrolę nad tym, kto co może zobaczyć. Przynajmniej na razie wydaje się, że duże instytucje finansowe wolą ukrywać większość transakcji w tych pośredniczących bazach danych, pomimo związanych z tym kosztów.

Ten wniosek opieram nie tylko na własnych doświadczeniach, ale także na kierunku, jaki obrało kilka znaczących startupów, których początkowym celem było stworzenie wspólnych ksiąg dla banków. Na przykład zarówno R3CEV, jak i Digital Asset pracują teraz nad „językami opisu umowy” w formacie Corda i DAML odpowiednio (wcześniejsze przykłady obejmują MLF i Ricardian Contracts). Języki te pozwalają na formalne i jednoznaczne przedstawienie warunków złożonej umowy finansowej w formacie czytelnym dla komputera, przy jednoczesnym uniknięciu niedociągnięcia obliczeń ogólnego przeznaczenia w stylu Ethereum. Zamiast tego, łańcuch bloków odgrywa tylko rolę pomocniczą, przechowując lub notarialnie umowy w postaci zaszyfrowanej i wykonując podstawowe wykrywanie duplikatów. Faktyczna realizacja umowy nie odbywa się w łańcuchu bloków - jest raczej wykonywana wyłącznie przez kontrahentów umowy, z prawdopodobnym dodatkiem audytorów i regulatorów.

W najbliższym czasie jest to prawdopodobnie najlepsze, co można zrobić, ale gdzie to pozostawia szersze ambicje dotyczące dozwolonych łańcuchów bloków? Czy są inne aplikacje, dla których mogą stanowić bardziej znaczącą część układanki?

Do tego pytania można podejść zarówno teoretycznie, jak i empirycznie. Teoretycznie, skupiając się na kluczowych różnicach między łańcuchami bloków a tradycyjnymi bazami danych oraz na tym, jak informują one o zestawie możliwych przypadków użycia. W naszym przypadku, empirycznie, kategoryzując rzeczywiste rozwiązania, które są obecnie budowane na MultiChain. Nic dziwnego, że niezależnie od tego, czy skupiamy się na teorii, czy praktyce, pojawiają się te same klasy przypadków użycia:

• Lekkie systemy finansowe.
• Śledzenie pochodzenia.
• Prowadzenie dokumentacji międzyorganizacyjnej.
• Agregacja wielostronna.

Zanim szczegółowo je wyjaśnimy, podsumujmy teorię. Tak jak ja omówione wcześniejdwie najważniejsze różnice między blockchainami a scentralizowanymi bazami danych można scharakteryzować w następujący sposób:

1. Disintermediation. Blockchain umożliwia wielu stronom, które nie ufają sobie w pełni, bezpieczne i bezpośrednie udostępnianie pojedynczej bazy danych bez konieczności korzystania z zaufanego pośrednika.
2. Poufność: Wszyscy uczestnicy łańcucha bloków widzą wszystkie transakcje, które mają miejsce. (Nawet jeśli używamy pseudonimowych adresów i zaawansowanej kryptografii, aby ukryć niektóre aspekty tych transakcji, łańcuch bloków zawsze będzie wyciekać więcej informacji niż scentralizowana baza danych).

Innymi słowy, łańcuchy bloków są idealne do współdzielonych baz danych, w których każdy użytkownik może czytać wszystko oprócz żadnego pojedynczego użytkownika kontroluje, kto może napisać co. Z kolei w tradycyjnych bazach danych pojedyncza jednostka sprawuje kontrolę nad wszystkimi operacjami odczytu i zapisu, podczas gdy inni użytkownicy podlegają całkowicie kaprysom tej jednostki. Podsumowując jednym zdaniem:

Blockchain to kompromis, w którym wyeliminowanie pośredników odbywa się kosztem poufności.

Analizując cztery rodzaje przypadków użycia poniżej, będziemy wielokrotnie powracać do tego podstawowego kompromisu, wyjaśniając, dlaczego w każdym przypadku korzyść z rezygnacji z pośrednictwa przewyższa koszt zmniejszonej poufności.

Lekkie systemy finansowe

Zacznijmy od najbardziej znanej klasy aplikacji blockchain, w których grupa podmiotów chce założyć system finansowy. W ramach tego systemu jeden lub więcej rzadkich aktywów jest przedmiotem transakcji i wymiany między tymi podmiotami.

W celu każdy zasobów, które mają pozostać rzadkie, należy rozwiązać dwa powiązane problemy. Po pierwsze, musimy upewnić się, że ta sama jednostka zasobu nie może zostać wysłana w więcej niż jedno miejsce („podwójne wydanie”). Po drugie, nikt nie może tworzyć nowych jednostek aktywów dla kaprysu („fałszerstwo”). Każdy podmiot, który mógłby zrobić którąkolwiek z tych rzeczy, mógłby ukraść nieograniczoną wartość z systemu.

Typowym rozwiązaniem tych problemów są fizyczne żetony, takie jak metalowe monety lub bezpiecznie zadrukowany papier. Te żetony w trywialny sposób rozwiązują problem podwójnego wydawania, ponieważ zasady fizyki (dosłownie) uniemożliwiają umieszczenie jednego żetonu w dwóch miejscach jednocześnie. Problem fałszerstwa rozwiązuje się, czyniąc żeton niezwykle trudnym do wyprodukowania. Mimo to fizyczne tokeny mają kilka niedociągnięć, które mogą sprawić, że będą niepraktyczne:

• Jako aktywa na okaziciela fizyczne tokeny mogą zostać skradzione bez śladu lub możliwości regresu.
• Poruszanie się ich w dużych ilościach lub na duże odległości jest powolne i kosztowne.
• Tworzenie fizycznych tokenów, których nie można sfałszować, jest trudne i kosztowne.

Tych niedociągnięć można uniknąć, pozostawiając fizyczne tokeny za sobą i przedefiniowując własność aktywów w formie księgi zarządzanej przez zaufanego pośrednika. W przeszłości księgi te były oparte na dokumentach papierowych, a obecnie działają w zwykłych bazach danych. Tak czy inaczej, pośrednik dokonuje przeniesienia prawa własności poprzez modyfikację treści księgi w odpowiedzi na uwierzytelnione żądanie. W przeciwieństwie do rozliczeń za pomocą fizycznych tokenów, wątpliwe transakcje można szybko i łatwo cofnąć.

Więc jaki jest problem z księgami? W skrócie, koncentracja kontroli. Umieszczając tak wielką władzę w jednym miejscu, tworzymy poważne wyzwanie bezpieczeństwa, zarówno pod względem technicznym, jak i ludzkim. Jeśli ktoś z zewnątrz może włamać się do bazy danych, może dowolnie zmieniać księgę, kradnąc fundusze innych osób lub całkowicie niszcząc jej zawartość. Co gorsza, ktoś W środku może uszkodzić księgę, a tego rodzaju atak jest trudny do wykrycia lub udowodnienia. W rezultacie wszędzie tam, gdzie mamy scentralizowaną księgę, musimy zainwestować znaczną ilość czasu i pieniędzy w mechanizmy utrzymania jej integralności. W wielu przypadkach wymagamy ciągłej weryfikacji za pomocą uzgadniania partiami między księgą centralną a księgami każdej ze stron transakcji.

Wprowadź łańcuch bloków (lub „wspólną księgę”). Zapewnia to korzyści z ksiąg rachunkowych bez problemu z koncentracją. Zamiast tego, każda jednostka prowadzi „węzeł”, w którym znajduje się kopia księgi i zachowuje pełną kontrolę nad własnymi aktywami, które są chronione kluczami prywatnymi. Transakcje propagują się między węzłami w sposób peer-to-peer, a łańcuch bloków zapewnia utrzymanie konsensusu. Ta architektura nie pozostawia centralnego punktu ataku, przez który haker lub osoba z wewnątrz mogłaby uszkodzić zawartość księgi. W rezultacie cyfrowy system finansowy można wdrożyć szybciej i taniej, z dodatkową korzyścią w postaci automatycznego uzgadniania w czasie rzeczywistym.

Więc jakie są wady? Jak wspomniano wcześniej, wszyscy uczestnicy wspólnej księgi widzą wszystkie transakcje, które mają miejsce, co czyni je bezużytecznymi w sytuacjach, w których wymagana jest poufność. Zamiast tego, łańcuchy bloków nadają się do tego, co nazywam lekki systemy finansowe, a mianowicie takie, w których udział ekonomiczny lub liczba uczestników jest stosunkowo niska. W takich przypadkach poufność jest zwykle mniejszym problemem - nawet jeśli uczestnicy zwracają baczną uwagę na to, co robią inni, nie nauczą się zbyt wiele. I to jest dokładnie bo stawki są niskie, dlatego wolimy uniknąć kłopotów i kosztów związanych z ustanowieniem pośrednika.

Niektóre oczywiste przykłady lekkich systemów finansowych obejmują: finansowanie społecznościowe, karty podarunkowe, punkty lojalnościowe i waluty lokalne - szczególnie w przypadkach, gdy aktywa można wymienić w więcej niż jednym miejscu. Ale obserwujemy również przypadki użycia w głównym nurcie sektora finansowego, takie jak handel peer-to-peer między zarządzającymi aktywami, którzy nie konkurują bezpośrednio. Blockchainy są nawet testowane jako wewnętrzny systemy księgowe w dużych organizacjach, w których każdy dział lub lokalizacja musi kontrolować swoje fundusze. We wszystkich tych przypadkach niższy koszt i tarcie łańcuchów bloków zapewnia natychmiastową korzyść, a utrata poufności nie jest problemem.

Śledzenie pochodzenia

Oto druga klasa przypadków użycia, które wielokrotnie słyszymy od użytkowników MultiChain: śledzenie pochodzenia i przepływu towarów o wysokiej wartości w łańcuchu dostaw, takich jak towary luksusowe, farmaceutyki, kosmetyki i elektronika. A także krytyczne elementy dokumentacji, takie jak listy przewozowe lub akredytywy. W łańcuchach dostaw rozciągających się w czasie i na odległość wszystkie te produkty podlegają podrabianiu i kradzieży.

Problem można rozwiązać za pomocą łańcuchów bloków w następujący sposób: gdy tworzony jest element o wysokiej wartości, zaufany podmiot wydaje odpowiedni token cyfrowy, który uwierzytelnia jego punkt pochodzenia. Następnie za każdym razem, gdy przedmiot fizyczny zmienia właściciela, token cyfrowy jest przesuwany równolegle, dzięki czemu łańcuch dostaw w świecie rzeczywistym jest dokładnie odzwierciedlany przez łańcuch transakcji w łańcuchu bloków.

Jeśli chcesz, token działa jak wirtualny „certyfikat autentyczności”, który jest znacznie trudniejszy do kradzieży lub podrobienia niż kawałek papieru. Po otrzymaniu cyfrowego tokena ostateczny odbiorca fizycznego przedmiotu, czy to bank, dystrybutor, sprzedawca czy klient, może zweryfikować łańcuch dostaw aż do punktu pochodzenia. Rzeczywiście, w przypadku dokumentacji, takiej jak listy przewozowe, możemy całkowicie pozbyć się elementu fizycznego.

Chociaż wszystko to ma sens, bystry czytelnik zauważy, że zwykła baza danych, zarządzana (powiedzmy) przez producenta przedmiotu, może wykonać to samo zadanie. Ta baza danych przechowuje zapis aktualnego właściciela każdego przedmiotu, akceptuje podpisane transakcje reprezentujące każdą zmianę własności i odpowiada na przychodzące żądania dotyczące aktualnego stanu rzeczy.

Dlaczego więc zamiast tego używać łańcucha bloków? Odpowiedź jest taka, że ​​w przypadku tego typu aplikacji istnieje korzyść z rozproszonego zaufania. Bez względu na to, gdzie przechowywana jest scentralizowana baza danych, w tym miejscu będą ludzie, którzy będą mogli (i mogą zostać przekupieni), aby uszkodzić jej zawartość, oznaczając sfałszowane lub skradzione przedmioty jako legalne. Z drugiej strony, jeśli pochodzenie jest śledzone na łańcuchu bloków należącym wspólnie do uczestników łańcucha dostaw, żaden pojedynczy podmiot lub mała grupa podmiotów nie może uszkodzić łańcucha dostaw, a użytkownicy końcowi mogą mieć większe zaufanie do otrzymywanych odpowiedzi. Jako bonus, różne tokeny (powiedzmy w przypadku niektórych towarów i odpowiadający im list przewozowy) mogą być bezpiecznie i bezpośrednio wymieniane, z dwustronną wymianą gwarantowane na najniższym poziomie blockchain.

A co z problemem poufności? Przydatność łańcuchów bloków do pochodzenia łańcucha dostaw jest dobrym wynikiem prostego schematu transakcji w tej aplikacji. W przeciwieństwie do rynków finansowych, większość tokenów porusza się w jednym kierunku, od źródła do punktu końcowego, bez wielokrotnego obrotu tam iz powrotem między uczestnikami łańcucha blokowego. Jeżeli konkurenci rzadko dokonują między sobą transakcji (np. Producent zabawek z producentem zabawek lub sprzedawca ze sprzedawcą detalicznym), nie mogą się wzajemnie poznać „adresów” łańcucha bloków i powiązać ich z rzeczywistymi tożsamościami. Ponadto działalność można łatwo podzielić na wiele ksiąg, z których każda reprezentuje inny porządek lub rodzaj towaru.

Prowadzenie dokumentacji międzyorganizacyjnej

Oba poprzednie przypadki użycia opierają się na tokenizowanych zasobach, tj. Łańcuchowych reprezentacjach elementu wartościowego przekazywanego między uczestnikami. Istnieje jednak druga grupa przypadków użycia blockchain, która nie jest związana z zasobami. Zamiast tego łańcuch działa jako mechanizm zbiorowego rejestrowania i poświadczania notarialnego każdy rodzaj danych, których znaczenie może być finansowe lub inne.

Jednym z takich przykładów jest ścieżka audytu krytycznej komunikacji między dwiema lub więcej organizacjami, powiedzmy w sektorze opieki zdrowotnej lub prawnym. Żadnej pojedynczej organizacji w grupie nie można ufać w utrzymywaniu tego archiwum rekordów, ponieważ sfałszowane lub usunięte informacje znacznie zaszkodziłyby innym. Niemniej jednak ważne jest, aby wszyscy zgodzili się co do zawartości archiwum, aby zapobiec sporom.

Aby rozwiązać ten problem, potrzebujemy współdzielonej bazy danych, w której zapisywane są wszystkie rekordy, a każdemu rekordowi towarzyszy znacznik czasu i dowód pochodzenia. Standardowym rozwiązaniem byłoby utworzenie zaufanego pośrednika, którego rolą jest centralne gromadzenie i przechowywanie rekordów. Ale łańcuchy bloków oferują inne podejście, dając organizacjom możliwość wspólnego zarządzania tym archiwum, jednocześnie uniemożliwiając poszczególnym uczestnikom (lub ich małym grupom) jego uszkodzenie.

Była to jedna z najbardziej pouczających rozmów, jakie odbyłem w ciągu ostatnich dwóch lat Michaela Mainelliego of Z / Yen. Jego firma od 20 lat buduje systemy, w których wiele podmiotów wspólnie zarządza wspólną cyfrową ścieżką audytu, stosując znaczniki czasu, podpisy cyfrowe i system konsensusu okrężnego. Kiedy wyjaśnił szczegóły techniczne tych systemów, stało się jasne, że pod każdym względem są one dozwolonymi łańcuchami bloków. Innymi słowy, nie ma nic nowego w używaniu łańcucha bloków do międzyorganizacyjnego prowadzenia dokumentacji - po prostu świat wreszcie uświadomił sobie taką możliwość.

Jeśli chodzi o rzeczywiste dane przechowywane w łańcuchu bloków, istnieją trzy popularne opcje:

• Niezaszyfrowane dane. Może to odczytać każdy uczestnik blockchain, zapewniając pełną zbiorową przejrzystość i natychmiastowe rozwiązanie w przypadku sporu.
• Zaszyfrowane dane. Mogą go odczytać tylko uczestnicy z odpowiednim kluczem odszyfrowywania. W przypadku sporu każdy może ujawnić ten klucz zaufanemu organowi, na przykład sądowi, i użyć łańcucha bloków, aby udowodnić, że oryginalne dane zostały dodane przez określoną stronę w określonym momencie.
• Zaszyfrowane dane. A „haszysz”Działa jak kompaktowy cyfrowy odcisk palca, reprezentujący zobowiązanie do określonego fragmentu danych, jednocześnie ukrywając te dane. Biorąc pod uwagę pewne dane, każda strona może łatwo potwierdzić, czy pasuje do danego skrótu, ale wnioskując z danych od jego hash jest obliczeniowo niemożliwy. Jedynie hash jest umieszczany w łańcuchu bloków, a oryginalne dane są przechowywane poza łańcuchem przez zainteresowane strony, które mogą je ujawnić w przypadku sporu.

Jak wspomniano wcześniej, produkt Corda firmy R3CEV przyjął to trzecie podejście, przechowywanie skrótów na blockchainie w celu notarialnego poświadczania umów między kontrahentami, bez ujawniania ich treści. Metodę tę można zastosować zarówno w przypadku opisów kontraktów w wersji komputerowej, jak i plików PDF zawierających dokumentację papierową.

Oczywiście poufność nie jest problemem w przypadku prowadzenia rejestrów między organizacjami, ponieważ celem jest stworzenie wspólnego archiwum, które wszyscy uczestnicy mogą zobaczyć (nawet jeśli niektóre dane są zaszyfrowane lub zaszyfrowane). Rzeczywiście, w niektórych przypadkach łańcuch bloków może pomóc w zarządzaniu dostępem do poufnych danych spoza łańcucha, zapewniając niezmienny zapis żądań dostępu podpisanych cyfrowo. Tak czy inaczej, bezpośrednią zaletą rezygnacji z pośrednictwa jest to, że nie trzeba tworzyć ani ufać żadnej dodatkowej encji, aby utrzymać ten rekord.

Agregacja wielostronna

Z technicznego punktu widzenia ta ostatnia klasa przypadków użycia jest podobna do poprzedniej, ponieważ wiele stron zapisuje dane w zbiorczo zarządzanym rekordzie. Jednak w tym przypadku motywacja jest inna - przezwyciężenie trudności infrastrukturalnych związanych z łączeniem informacji z dużej liczby odrębnych źródeł.

Wyobraź sobie dwa banki z wewnętrznymi bazami danych weryfikacji tożsamości klientów. W pewnym momencie zauważają, że mają wielu wspólnych klientów, więc zawierają umowę o wzajemnym udostępnianiu, w której wymieniają dane weryfikacyjne, aby uniknąć powielania pracy. Technicznie umowa realizowana jest standardowo replikacja danych typu master-slave, w którym każdy bank utrzymuje kopię działającą tylko do odczytu bazy danych drugiego i wykonuje zapytania równolegle do swojej własnej bazy danych i repliki. Na razie w porządku.

Teraz wyobraź sobie, że te dwa banki zapraszają trzy inne osoby do udziału w tym kręgu udostępniania. Każdy z 5 banków posiada własną główną bazę danych wraz z 4 replikami tylko do odczytu pozostałych. Przy 5 wzorcach i 20 replikach mamy łącznie 25 instancji bazy danych. Chociaż jest to wykonalne, pochłania to zauważalny czas i zasoby w dziale IT każdego banku.

Szybko do przodu do punktu, w którym 20 banków dzieli się informacjami w ten sposób, a łącznie przyglądamy się 400 instancjom baz danych. W przypadku 100 banków osiągamy 10,000 XNUMX instancji. Ogólnie rzecz biorąc, jeśli każda ze stron udostępnia sobie informacje, całkowita liczba instancji bazy danych rośnie wraz z kwadratem liczby uczestników. W pewnym momencie tego procesu system jest skazany na awarię.

Więc jakie jest rozwiązanie? Jedną z oczywistych opcji jest, aby wszystkie banki przekazały swoje dane zaufanemu pośrednikowi, którego zadaniem jest agregowanie tych danych w jednej głównej bazie danych. Każdy bank mógłby następnie wysłać zapytanie do tej bazy danych zdalnie lub uruchomić lokalną replikę tylko do odczytu w swoich czterech ścianach. Chociaż nie ma nic złego w tym podejściu, łańcuchy bloków oferują tańszą alternatywę, w której współdzielona baza danych jest obsługiwana bezpośrednio przez banki, które z niej korzystają. Blockchainy również przynoszą dodatkowe korzyści nadmierność i praca awaryjna dla całego systemu.

Ważne jest, aby wyjaśnić, że łańcuch bloków nie działa tak jak rozproszona baza danych Cassandra or Przemyśl DB. W przeciwieństwie do tych systemów, każdy węzeł blockchain wymusza zestaw reguł, które uniemożliwiają jednemu uczestnikowi modyfikowanie lub usuwanie danych dodanych przez drugiego. Rzeczywiście, nadal wydaje się, że jest co do tego pewne zamieszanie - jedna niedawno wydana platforma blockchain może zostać złamana przez pojedynczy źle działający węzeł. W każdym razie dobra platforma ułatwi również zarządzanie sieciami z tysiącami węzłów, dołączaniem i opuszczaniem do woli, jeśli otrzyma się odpowiednie uprawnienia.

Chociaż jestem trochę sceptyczny co do często cytowanego związku między łańcuchami bloków a Internet przedmiotówMyślę, że to może być tam, gdzie leży silna taka synergia. Oczywiście każda „rzecz” byłaby zbyt mała, aby przechowywać lokalnie pełną kopię łańcucha bloków. Raczej przekazywałby transakcje zawierające dane do rozproszonej sieci węzłów blockchain, które zestawiałyby je wszystkie razem w celu dalszego wyszukiwania i analizy.

Wniosek: Blockchain w finansach

Zacząłem ten artykuł od zakwestionowania początkowego przypadku użycia przewidzianego dla łańcuchów bloków w sektorze finansowym, a mianowicie masowego rozliczania płatności i transakcji wymiany. Chociaż uważam, że ten wniosek staje się powszechną mądrością (z jednym wyjątek godny uwagi), nie oznacza to, że blockchainy nie mają innych zastosowań w tej branży. W rzeczywistości dla każdej z czterech klas opisanych powyżej przypadków użycia widzimy przejrzyste aplikacje dla banków i innych instytucji finansowych. Są to odpowiednio: małe kręgi handlowe, źródło finansowania handlu, notarialna umowa dwustronna oraz agregacja danych AML / KYC.

Kluczem do zrozumienia jest to, że pod względem architektonicznym nasze cztery klasy przypadków użycia nie są specyficzny finansowania i są równie istotne dla innych sektorów, takich jak ubezpieczenia, opieka zdrowotna, dystrybucja, produkcja i IT. Rzeczywiście, prywatne łańcuchy bloków powinny być brane pod uwagę w każdej sytuacji, w której dwie lub więcej organizacji potrzebuje wspólnego poglądu na rzeczywistość, a pogląd ten nie pochodzi z jednego źródła. W takich przypadkach łańcuchy bloków stanowią alternatywę dla zaufanego pośrednika, co prowadzi do znacznych oszczędności w zakresie kłopotów i kosztów.

Prosimy o umieszczanie komentarzy na LinkedIn.

Źródło: https://www.multichain.com/blog/2016/05/four-g Genuine-blockchain-use-cases/