Négy valódi blokklánc használati eset

Ahol a megosztott főkönyvek valódi értéket adnak a vállalati IT-ben

Majdnem egy évvel az első megjelenés után MultiChain, rengeteget tanultunk arról, hogy a privát és nem kriptovaluta értelemben vett blokkláncok hogyan alkalmazhatók és nem alkalmazhatók valós problémákra. Engedjék meg, hogy megosszam, amit eddig tudunk.

Kezdjük azzal, hogy az első ötlet, amellyel mi (és sokan mások is) elindultunk, tévesnek tűnik. Ez az ötlet, amelyet közvetlenül a bitcoin ihletett, az volt, hogy a privát blokkláncok (vagy „megosztott főkönyvek”) közvetlenül felhasználhatók a pénzügyi szektor fizetési és cseretranzakcióinak többségének közvetlen rendezésére, a láncon belüli tokenekkel készpénz, részvények, kötvények és több.

Ez technikailag tökéletesen működőképes, akkor mi a probléma? Egy szóban, titoktartási. Ha több intézmény használ megosztott főkönyvet, akkor minden intézmény lát minden tranzakciót a főkönyvben, még akkor is, ha nem ismeri azonnal az érintett felek valós kilétét. Ez óriási kérdésnek bizonyul, mind a szabályozás, mind a bankközi verseny kereskedelmi realitása szempontjából. Noha különböző stratégiák állnak rendelkezésre vagy fejlesztés alatt állnak a probléma enyhítésére, egyik sem fér össze egy megbízható közvetítő által kezelt központosított adatbázis egyszerűségével és hatékonyságával, amely teljes ellenőrzést tart fenn arra vonatkozóan, hogy ki mit láthat. Legalábbis egyelőre úgy tűnik, hogy a nagy pénzintézetek az ezzel járó költségek ellenére a legtöbb tranzakciót inkább ezekben a közvetítő adatbázisokban rejtik el.

Ezt a következtetést nem csak saját tapasztalatainkra alapozom, hanem arra az irányra is, amelyet több prominens startup követett el, akiknek eredeti célja az volt, hogy közös bankkönyveket dolgozzanak ki. Például mind az R3CEV, mind a Digital Asset jelenleg a „szerződésleíró nyelveken” dolgozik Corda és a DAML illetve (korábbi példák közé tartozik MLFi és a Ricardo szerződések). Ezek a nyelvek lehetővé teszik egy összetett pénzügyi szerződés feltételeinek formális és egyértelmű megjelenítését számítógéppel olvasható formátumban, elkerülve a hiányosságokat Ethereum-stílusú általános célú számítás. Ehelyett a blokklánc csak támogató szerepet tölt be, titkosított formában tárolja vagy hitelesíti a szerződéseket, és néhány alapvető duplikátum-észlelést végez. A szerződés tényleges végrehajtása nem a blokkláncon történik, hanem csak a szerződésben szereplő felek hajtják végre, valószínűleg auditorok és szabályozók hozzáadásával.

A közeljövőben valószínűleg ez a legjobb, amit meg lehet tenni, de hol marad ez az engedélyezett blokkláncokra vonatkozó szélesebb ambíció? Vannak más alkalmazások, amelyeknél jelentősebb részét képezhetik a rejtvénynek?

Ezt a kérdést elméletileg és empirikusan is meg lehet közelíteni. Elméletileg azáltal, hogy a blokkláncok és a hagyományos adatbázisok közötti kulcsfontosságú különbségekre összpontosítunk, és arra, hogy ezek hogyan tájékoztatják a lehetséges használati eseteket. Esetünkben pedig empirikusan, a MultiChainre ma épülő valós megoldások kategorizálásával. Nem meglepő, hogy akár az elméletre, akár a gyakorlatra összpontosítunk, ugyanazok a használati esetosztályok merülnek fel:

• Könnyű pénzügyi rendszerek.
• Származási hely nyomon követése.
• Szervezetközi nyilvántartás.
• Többpárti aggregáció.

Mielőtt ezeket részletesen kifejtenénk, foglaljuk össze az elméletet. Ahogy én is korábban tárgyalták, a blokkláncok és a központosított adatbázisok közötti két legfontosabb különbség a következőképpen jellemezhető:

1. kiiktatása. A blokkláncok lehetővé teszik több, egymásban nem teljesen megbízó fél számára, hogy biztonságosan és közvetlenül megosszák egyetlen adatbázist anélkül, hogy megbízható közvetítőre lenne szükségük.
2. Titoktartás: A blokklánc minden résztvevője látja az összes lezajlott tranzakciót. (Még ha álnevű címeket és fejlett kriptográfiát használunk is a tranzakciók bizonyos aspektusainak elrejtésére, a blokklánc mindig több információt szivárog ki, mint egy központi adatbázis.)

Más szóval, a blokkláncok ideálisak olyan megosztott adatbázisokhoz, amelyekben minden felhasználó képes rá olvas mindent, de nincs egyetlen felhasználó sem irányítja, aki teheti ír mit. Ezzel szemben a hagyományos adatbázisokban egyetlen entitás irányítja az összes olvasási és írási műveletet, míg a többi felhasználó teljes mértékben ki van téve az entitás szeszélyeinek. Egy mondatban összefoglalva:

A blokkláncok olyan kompromisszumot jelentenek, amelyben a közvetítés hiánya a titoktartás árán történik.

Az alábbi négy típusú felhasználási eset vizsgálata során ismételten visszatérünk ehhez az alapvető kompromisszumhoz, és elmagyarázzuk, hogy a közvetítés hiánya minden esetben miért haladja meg a csökkentett titoktartás költségeit.

Könnyű pénzügyi rendszerek

Kezdjük a blokklánc alkalmazások legismertebb osztályával, amelyben entitások egy csoportja pénzügyi rendszert kíván felállítani. Ezen a rendszeren belül egy vagy több szűkös eszközt bonyolítanak le és cserélnek ki az említett entitások között.

Annak érdekében, hogy bármilyen hogy az eszközök szűkösek maradjanak, két kapcsolódó problémát kell megoldani. Először is gondoskodnunk kell arról, hogy az eszköz ugyanazt az egységét ne lehessen egynél több helyre küldeni („dupla költés”). Másodszor, lehetetlennek kell lennie, hogy valaki szeszélyből új egységeket hozzon létre az eszközből („hamisítás”). Bármely entitás, amely megteheti a fentiek bármelyikét, korlátlan értéket lophat el a rendszerből.

E problémák általános megoldása a fizikai tokenek, például fémérmék vagy biztonságosan nyomtatott papír. Ezek a tokenek triviálisan megoldják a dupla költés problémáját, mert a fizika szabályai (szó szerint) megakadályozzák, hogy egy token egyszerre két helyen legyen. A hamisítás problémáját úgy oldják meg, hogy rendkívül megnehezítik a token gyártását. Ennek ellenére a fizikai tokenek számos olyan hiányosságtól szenvednek, amelyek kivitelezhetetlenné tehetik őket:

• A fizikai tokenek, mint tisztán hordozói eszközök, nyom vagy jogorvoslat nélkül ellophatók.
• Lassúak és költségesek nagy számban vagy nagy távolságra történő mozgásuk.
• Bonyolult és költséges olyan fizikai tokeneket létrehozni, amelyeket nem lehet hamisítani.

Ezek a hiányosságok elkerülhetők a fizikai tokenek hátrahagyásával, és az eszközök tulajdonjogának újradefiniálásával egy megbízható közvetítő által kezelt főkönyvben. Korábban ezek a főkönyvek papíralapú nyilvántartásokon alapultak, ma pedig általában rendszeres adatbázisokon futnak. Akárhogy is, a közvetítő a tulajdonjog átruházását a főkönyv tartalmának módosításával, hitelesített kérésre válaszul hajtja végre. A fizikai tokenekkel való elszámolástól eltérően a megkérdőjelezhető tranzakciók gyorsan és egyszerűen visszafordíthatók.

Tehát mi a probléma a főkönyvekkel? Dióhéjban, a kontroll koncentrációja. Azzal, hogy ennyi erőt helyezünk egy helyre, jelentős biztonsági kihívást jelentünk, mind technikai, mind emberi szempontból. Ha valaki külső feltörheti az adatbázist, akkor tetszés szerint megváltoztathatja a főkönyvet, ellopva mások pénzét, vagy teljesen megsemmisítve annak tartalmát. Még rosszabb, valaki belül tönkreteheti a főkönyvet, és ezt a fajta támadást nehéz észlelni vagy bizonyítani. Ennek eredményeként, ahol van központi főkönyvünk, jelentős időt és pénzt kell fektetnünk olyan mechanizmusokba, amelyek a főkönyv integritását megőrzik. És sok esetben folyamatos ellenőrzésre van szükségünk kötegalapú egyeztetéssel a központi főkönyv és az egyes tranzakciós felek között.

Írja be a blokkláncot (vagy „megosztott főkönyvet”). Ez biztosítja a főkönyvek előnyeit anélkül, hogy a koncentráció problémáitól szenvedne. Ehelyett minden entitás egy „csomópontot” futtat, amely a főkönyv másolatát tartalmazza, és teljes ellenőrzést tart fenn saját eszközei felett, amelyeket privát kulcsok védenek. A tranzakciók a csomópontok között peer-to-peer módon terjednek, és a blokklánc biztosítja a konszenzus fenntartását. Ez az architektúra nem hagy olyan központi támadási pontot, amelyen keresztül egy hacker vagy bennfentes megrongálhatná a főkönyv tartalmát. Ennek eredményeként a digitális pénzügyi rendszer gyorsabban és olcsóbban telepíthető, és további előnye a valós idejű automatikus egyeztetés.

Tehát mi a hátránya? Amint azt korábban tárgyaltuk, a megosztott főkönyv minden résztvevője látja az összes megtörtént tranzakciót, így használhatatlanná válik olyan helyzetekben, amikor titoktartásra van szükség. Ehelyett a blokkláncok alkalmasak arra, amit én hívok könnyűsúlyú pénzügyi rendszerek, nevezetesen azok, amelyekben a gazdasági tét vagy a résztvevők száma viszonylag alacsony. Ezekben az esetekben a titoktartás általában kevésbé jelent problémát – még ha a résztvevők nagyon odafigyelnek is egymás tevékenységére, nem tanulnak sok értéket. És pontosan az mert csekély a tét, hogy inkább elkerüljük a közvetítő felállításával járó gondokat és költségeket.

Néhány nyilvánvaló példa a könnyű pénzügyi rendszerekre: közösségi finanszírozás, ajándékkártyák, hűségpontok és helyi pénznemek – különösen olyan esetekben, amikor az eszközök egynél több helyen válthatók be. De a mainstream pénzügyi szektorban is tapasztalunk felhasználási eseteket, például peer-to-peer kereskedést olyan eszközkezelők között, akik nem állnak közvetlen versenyben. A blokkláncokat még tesztelik is belső számviteli rendszerek, nagy szervezetekben, ahol minden részlegnek vagy telephelynek fenn kell tartania az alapok ellenőrzését. Mindezekben az esetekben a blokkláncok alacsonyabb költsége és súrlódása azonnali előnyt jelent, miközben a titoktartás elvesztése nem aggaszt.

Származási hely nyomon követése

Íme egy második használati eset, amelyet többször hallunk a MultiChain felhasználóitól: a nagy értékű cikkek eredetének és mozgásának nyomon követése az ellátási láncon keresztül, például luxuscikkek, gyógyszerek, kozmetikumok és elektronikai cikkek. Ugyanígy a kritikus dokumentumelemek, például a fuvarlevelek vagy az akkreditívek. Az időben és távolságon átnyúló ellátási láncokban ezek a termékek mindegyike szenved hamisítástól és lopástól.

A probléma a következő módon kezelhető blokkláncokkal: a nagy értékű elem létrehozásakor egy megbízható entitás bocsát ki egy megfelelő digitális tokent, amely hitelesíti a kiindulási pontot. Ezután minden alkalommal, amikor a fizikai tétel gazdát cserél, a digitális tokent párhuzamosan mozgatják, így a valós világ felügyeleti láncát pontosan tükrözi a blokkláncon lévő tranzakciók lánca.

Ha úgy tetszik, a token virtuális „eredetiségi bizonyítványként” működik, amelyet sokkal nehezebb ellopni vagy hamisítani, mint egy darab papírt. A digitális token kézhezvételekor a fizikai cikk végső címzettje, legyen az bank, forgalmazó, kiskereskedő vagy vásárló, ellenőrizheti a felügyeleti láncot egészen a származási helyig. Valójában az olyan dokumentumok esetében, mint a fuvarlevelek, teljesen megszüntethetjük a fizikai tételt.

Bár mindez logikus, az okos olvasó észre fogja venni, hogy egy rendszeres adatbázis, amelyet (mondjuk) egy cikk gyártója kezel, képes elvégezni ugyanezt a feladatot. Ez az adatbázis tárolja az egyes elemek jelenlegi tulajdonosának rekordját, elfogadja az aláírt tranzakciókat, amelyek minden tulajdonosváltásra utalnak, és válaszol a beérkező kérésekre az aktuális állapottal kapcsolatban.

Akkor miért használjunk blokkláncot helyette? A válasz az, hogy az ilyen típusú alkalmazásoknál előnyt jelent az elosztott bizalom. Függetlenül attól, hogy hol tárolják a központosított adatbázist, ott lesznek olyan emberek, akik képesek (és megvesztegethetők) megrontani annak tartalmát, és a hamisított vagy ellopott tárgyakat legálisnak jelölik. Ezzel szemben, ha a származást az ellátási lánc résztvevőihez együttesen tartozó blokkláncon követik nyomon, egyetlen entitás vagy entitások kis csoportja sem tudja megrontani a felügyeleti láncot, és a végfelhasználók jobban bízhatnak a kapott válaszokban. Bónuszként a különböző tokenek (mondjuk egyes áruk és a megfelelő fuvarlevél) biztonságosan és közvetlenül cserélhetők, kétirányú cserével Garantált a legalacsonyabb blokklánc szinten.

Mi a helyzet a titoktartás problémájával? A blokkláncoknak az ellátási lánc eredetére való alkalmassága az alkalmazás egyszerű tranzakciós mintájának boldog eredménye. A pénzügyi piacokkal ellentétben a legtöbb tokenek egyetlen irányba mozognak, a kiindulási ponttól a végpontig anélkül, hogy ismételten oda-vissza kereskednének velük a blokklánc résztvevői között. Ha a versenytársak ritkán kötnek egymással tranzakciókat (pl. a játékgyártótól a játékgyártóig vagy a kiskereskedőtől a kiskereskedőig), nem tudják megtanulni egymás blokklánc „címeit”, és nem tudják összekapcsolni azokat a valós identitásokkal. Ezenkívül a tevékenység könnyen felosztható több főkönyvre, amelyek mindegyike más-más megrendelést vagy árutípust képvisel.

Szervezetközi nyilvántartás

Mindkét korábbi felhasználási eset tokenizált eszközökön alapul, azaz a résztvevők között átadott érték láncon belüli megjelenítésén. Van azonban a blokklánc használati eseteinek egy második csoportja, amely nem kapcsolódik az eszközökhöz. Ehelyett a lánc a közös rögzítés és a közjegyzői hitelesítés mechanizmusaként működik bármilyen típusú adatok, amelyek jelentése lehet pénzügyi vagy egyéb.

Ilyen például a két vagy több szervezet közötti kritikus kommunikáció ellenőrzési nyomvonala, például az egészségügyi vagy jogi szektorban. A csoport egyetlen szervezete sem bízható meg ennek az irattárnak a gondozásában, mert a meghamisított vagy törölt információk jelentősen károsítanák a többieket. Mindazonáltal létfontosságú, hogy a viták elkerülése érdekében mindenki egyetértsen az archívum tartalmával.

A probléma megoldásához szükségünk van egy megosztott adatbázisra, amelybe az összes rekord be van írva, minden rekordhoz időbélyeggel és származási igazolással kell ellátni. A szokásos megoldás egy megbízható közvetítő létrehozása lenne, akinek a feladata az iratok központi összegyűjtése és tárolása. A blokkláncok azonban más megközelítést kínálnak, lehetőséget adva a szervezeteknek, hogy közösen kezeljék ezt az archívumot, miközben megakadályozzák, hogy az egyes résztvevők (vagy azok kis csoportjai) megsértsék azt.

Az elmúlt két évben az egyik legmegvilágosítóbb beszélgetésem vele volt Michael Mainelli of Z / Yen. Cége 20 éve épít olyan rendszereket, amelyekben több entitás közösen kezel egy megosztott digitális ellenőrzési nyomvonalat, időbélyegzést, digitális aláírást és egy körmérkőzéses konszenzus sémát használva. Ahogy elmagyarázta ezeknek a rendszereknek a technikai részleteit, világossá vált, hogy minden tekintetben engedélyezett blokkláncok. Vagyis semmi újdonság nincs abban, hogy a blokkláncot szervezetközi nyilvántartásra használjuk – pusztán arról van szó, hogy a világ végre tudomást szerzett ennek lehetőségéről.

A blokkláncon tárolt tényleges adatok tekintetében három népszerű lehetőség van:

• Titkosítatlan adatok. Ezt a blokklánc minden résztvevője elolvashatja, teljes kollektív átláthatóságot és azonnali megoldást biztosítva vita esetén.
• Titkosított adatok. Ezt csak a megfelelő visszafejtő kulccsal rendelkező résztvevők olvashatják. Vita esetén bárki felfedheti ezt a kulcsot egy megbízható hatóságnak, például bíróságnak, és a blokklánc segítségével bizonyíthatja, hogy az eredeti adatokat egy adott fél adta hozzá egy adott időpontban.
• Kivonatolt adatok. A „hash” kompakt digitális ujjlenyomatként működik, egy adott adatrész iránti elkötelezettséget jelképezve, miközben az adatokat rejtve tartja. Egyes adatok birtokában bármelyik fél könnyen megerősítheti, hogy megfelel-e egy adott hash-nek, de kikövetkeztetheti az adatokat ból ből a hash-je számításilag lehetetlen. Csak a hash kerül a blokkláncra, az eredeti adatokat a láncon kívül tárolják az érdeklődők, akik vita esetén felfedhetik.

Ahogy korábban említettük, az R3CEV Corda terméke ezt a harmadik megközelítést alkalmazta, hashek tárolása blokkláncon a szerződő felek közötti szerződések közjegyzői hitelesítésére anélkül, hogy azok tartalmát felfednék. Ez a módszer használható mind a számítógéppel olvasható szerződésleírásokhoz, mind a papíralapú dokumentációt tartalmazó PDF-fájlokhoz.

A titoktartás természetesen nem probléma a szervezetközi nyilvántartásban, mert a teljes cél egy megosztott archívum létrehozása, amelyet minden résztvevő láthat (még akkor is, ha egyes adatok titkosítva vagy kivonatolva vannak). Valójában bizonyos esetekben a blokklánc segíthet a bizalmas, láncon kívüli adatokhoz való hozzáférés kezelésében azáltal, hogy megváltoztathatatlan rekordot biztosít a digitálisan aláírt hozzáférési kérelmekről. Akárhogy is, a közvetítés megszüntetésének egyértelmű előnye, hogy nem kell további entitást létrehozni, és nem kell megbízni a rekord karbantartásában.

Többpárti aggregáció

Technikailag ez a használati eset utolsó osztálya hasonló az előzőhöz, mivel több fél ír adatokat egy közösen kezelt rekordba. Ebben az esetben azonban más a motiváció – a nagyszámú, különálló forrásból származó információ kombinálásának infrastrukturális nehézségeinek leküzdése.

Képzeljen el két bankot, amelyek belső adatbázisokkal rendelkeznek az ügyfelek személyazonosságának ellenőrzésére. Egy bizonyos ponton észreveszik, hogy sok vásárlójuk van, ezért kölcsönös megosztási megállapodást kötnek, amelyben ellenőrző adatokat cserélnek, hogy elkerüljék a párhuzamos munkavégzést. Technikailag a megállapodást szabvány szerint hajtják végre mester–szolga adatreplikáció, amelyben minden bank fenntartja a másik adatbázisának élő, csak olvasható másolatát, és párhuzamosan lekérdezéseket futtat a saját adatbázisában és a replikában. Eddig jó.

Most képzelje el, hogy ez a két bank meghív három másikat, hogy vegyenek részt ebben a megosztási körben. Mind az 5 bank saját főadatbázist futtat, a többi 4 írásvédett másolatával együtt. 5 mesterrel és 20 replikával összesen 25 adatbázispéldányunk van. Bár megvalósítható, ez észrevehető időt és erőforrásokat emészt fel az egyes bankok informatikai részlegén.

Gyorsan előre odáig, hogy 20 bank oszt meg ilyen módon információkat, és összesen 400 adatbázispéldányt vizsgálunk. 100 bank esetében elérjük a 10,000 XNUMX példányt. Általánosságban elmondható, hogy ha minden fél megosztja egymással az információkat, az adatbázispéldányok teljes száma a résztvevők számának négyzetével nő. A folyamat egy bizonyos pontján a rendszer összeomlik.

Szóval mi a megoldás? Az egyik kézenfekvő lehetőség, hogy minden bank elküldi adatait egy megbízható közvetítőnek, akinek az a feladata, hogy ezeket az adatokat egyetlen törzsadatbázisban összesítse. Ezután minden bank távolról lekérdezheti ezt az adatbázist, vagy futtathat egy helyi, csak olvasható replikát a saját négy falán belül. Bár ezzel a megközelítéssel nincs semmi baj, a blokkláncok olcsóbb alternatívát kínálnak, amelyben a megosztott adatbázist közvetlenül az azt használó bankok működtetik. A blokkláncok további előnye is a redundancia és a failover a rendszer egészére nézve.

Fontos tisztázni, hogy a blokklánc nem úgy működik, mint egy elosztott adatbázis, mint például Cassandra or ÚjragondolásDB. Ezekkel a rendszerekkel ellentétben minden blokklánc-csomópont olyan szabályokat kényszerít ki, amelyek megakadályozzák, hogy az egyik résztvevő módosítsa vagy törölje a másik által hozzáadott adatokat. Valójában még mindig van némi zűrzavar ezzel kapcsolatban – egy nemrégiben kiadott blokklánc-platformot egyetlen hibásan viselkedő csomópont megtörhet. Mindenesetre egy jó platform megkönnyíti a több ezer csomópontból álló hálózatok kezelését, amelyek tetszés szerint csatlakoznak és távoznak, ha megkapják a megfelelő engedélyeket.

Bár kissé szkeptikus vagyok a blokkláncok és a A tárgyak internete, azt hiszem, itt lehet egy ilyen erős szinergia. Természetesen minden „dolog” túl kicsi lenne ahhoz, hogy a blokklánc teljes másolatát helyben tároljuk. Inkább az adathordozó tranzakciókat a blokklánc csomópontok elosztott hálózatába továbbítaná, akik az összeset összevonják további visszakeresés és elemzés céljából.

Következtetés: Blokkláncok a pénzügyekben

Ezt a cikket azzal kezdtem, hogy megkérdőjeleztem a blokkláncok kezdeti felhasználási esetét a pénzügyi szektorban, nevezetesen a fizetési és csereügyletek tömeges elszámolását. Bár úgy gondolom, hogy ez a következtetés általános bölcsességgé válik (egy figyelemre méltó kivétel), ez nem jelenti azt, hogy a blokkláncoknak nincs más alkalmazása ebben az iparágban. Valójában a fent vázolt négy felhasználási osztály mindegyikére egyértelmű alkalmazásokat látunk a bankok és más pénzintézetek számára. Illetve ezek: kis kereskedőkörök, származás a kereskedelem finanszírozásához, kétoldalú szerződések közjegyzői hitelesítése és az AML/KYC adatok összesítése.

A legfontosabb, hogy megértsük, hogy építészetileg négy használati osztályunk nem az különleges finanszírozására, és ugyanolyan fontosak más ágazatokban, mint például a biztosítás, az egészségügy, a forgalmazás, a gyártás és az IT. Valójában minden olyan helyzetben fontolóra kell venni a privát blokkláncokat, amelyekben két vagy több szervezetnek közös nézetre van szüksége a valóságról, és ez a nézet nem egyetlen forrásból származik. Ezekben az esetekben a blokkláncok alternatívát kínálnak a megbízható közvetítő iránt, ami jelentős probléma- és költségmegtakarítást eredményez.

Kérjük, tegye meg észrevételeit a LinkedIn.

Forrás: https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/