Neli ehtsat plokiahela kasutamise juhtumit

Kui ühised pearaamatud lisavad ettevõtte IT-le tõelist väärtust

Peaaegu aasta pärast esimest vabastamist MultiCin, oleme õppinud tohutult palju selle kohta, kuidas plokiahelaid privaatses ja mitte-krüptoraha mõistes saab ja ei saa reaalsetes probleemides rakendada. Lubage mul jagada seda, mida me seni teame.

Alustuseks näib, et esimene mõte, millest me (ja paljud teised) alustasime, on vale. See idee, mis oli inspireeritud otseselt bitcoinist, oli see, et privaatset plokiahelat (või "jagatud raamatupidamisraamatut") saab kasutada suurema osa makse- ja vahetustehingute arveldamiseks otse finantssektoris, kasutades ahelas olevaid märke sularaha, aktsiate, võlakirjade ja rohkem.

See on tehniliselt täiesti toimiv, nii et milles on probleem? Ühesõnaga, konfidentsiaalsus. Kui jagatud pearaamatut kasutab mitu asutust, näeb iga asutus selle pearaamatu kõiki tehinguid, isegi kui nad ei tea kohe asjaosaliste tegelikku identiteeti. See osutub tohutuks probleemiks nii reguleerimise kui ka pankadevahelise konkurentsi kaubandusliku tegelikkuse osas. Kuigi selle probleemi leevendamiseks on saadaval või väljatöötamisel mitmesuguseid strateegiaid, ei suuda ükski neist olla usaldusväärse vahendaja hallatava tsentraliseeritud andmebaasi lihtsuse ja tõhususega, mis säilitab täieliku kontrolli selle üle, kes mida näeb. Vähemalt praegu tundub, et suured finantsasutused eelistavad enamikke tehinguid vaatamata kaasnevatele kulutustele peita nendes vahendaja andmebaasides.

Lähtun sellest järeldusest mitte ainult meie enda kogemustest, vaid ka suunast, mille on võtnud mitu silmapaistvat idufirmat, kelle esialgne eesmärk oli arendada pankadele ühiseid raamatuid. Näiteks töötavad nii R3CEV kui ka Digital Asset nüüd lepingukirjelduse keelte kallal Corda ja DAML vastavalt (varasemate näidete hulka kuuluvad MLFi ja Ricardian lepingud). Need keeled võimaldavad keeruka finantslepingu tingimusi esitada formaalselt ja ühemõtteliselt arvutil loetavas vormingus, vältides samas puudused Ethereumi stiilis üldotstarbelist arvutamist. Selle asemel mängib plokiahel ainult tugirolli, lepingute krüptitud kujul salvestamine või notariaalne kinnitamine ning mõne põhilise duplikaadi tuvastamise teostamine. Lepingu tegelik täitmine ei toimu plokiahelas - pigem täidavad seda ainult lepingu osapooled, lisades tõenäoliselt ka audiitorid ja reguleerivad asutused.

Lähitulevikus on see ilmselt parim, mida teha saab, kuid kuhu jätab see loa saanud plokiahelate jaoks laiemad ambitsioonid? Kas on muid rakendusi, mille jaoks need võivad mõistatuse olulisema osa moodustada?

Sellele küsimusele saab läheneda nii teoreetiliselt kui ka empiiriliselt. Teoreetiliselt, keskendudes põhilistele erinevustele plokiahelate ja traditsiooniliste andmebaaside vahel ning sellele, kuidas need võimalike kasutusjuhtude kogumit teavitavad. Ja meie puhul, empiiriliselt, liigitades reaalainete lahendused, millele täna MultiChain tugineb. Pole üllatav, kui keskendume teooriale või praktikale, tekivad samad kasutusjuhtumite klassid:

• Kerged finantssüsteemid.
• Päritolu jälgimine.
• Organisatsioonidevaheline arvepidamine.
• Mitmeparteiline liitmine.

Enne nende üksikasjalikku selgitamist võtame teooria uuesti kokku. Nagu ma olen teinud varem arutatud, saab kahte kõige olulisemat erinevust plokiahelate ja tsentraliseeritud andmebaaside vahel iseloomustada järgmiselt:

1. Disintermediatsioon. Plokiahelad võimaldavad mitmel osapoolel, kes ei usalda üksteist, ohutult ja otse ühist andmebaasi ilma usaldusväärse vahendaja nõudmiseta.
2. Konfidentsiaalsus: Kõik plokiahelas osalejad näevad kõiki toimuvaid tehinguid. (Isegi kui nende tehingute mõningaid aspekte peidame pseudonüümsete aadresside ja täpsema krüptograafia abil, lekitab blockchain alati rohkem teavet kui tsentraliseeritud andmebaas.)

Teisisõnu on plokiahelad ideaalsed jagatud andmebaaside jaoks iga kasutaja on võimeline lugenud kõik, aga pole ühtegi kasutajat kontrollib, kes saab kirjutama mida. Seevastu traditsioonilistes andmebaasides teostab üksus kõigi lugemis- ja kirjutamistoimingute üle kontrolli, samas kui teised kasutajad alluvad täielikult selle üksuse kapriisidele. Selle ühe lausega kokku võttes:

Plokiahelad kujutavad endast kompromissi, mille käigus jagamine toimub konfidentsiaalsuse hinnaga.

Allpool toodud nelja kasutusjuhtumi tüüpi uurides jõuame korduvalt selle põhilise kompromissini, selgitades, miks mõlemal juhul kaalub desintegreerimisega kaasnev kasu vähenenud konfidentsiaalsuse kulud.

Kerged finantssüsteemid

Alustame kõige paremini tuttava plokiahelarakenduste klassiga, kus üksuste rühm soovib luua finantssüsteemi. Selles süsteemis toimub nende üksuste vahel tehingute tegemine ja vahetamine ühe või mitme piiratud varaga.

Selleks, et mistahes varade nappus, tuleb lahendada kaks seotud probleemi. Esiteks peame tagama, et sama varaühikut ei saaks saata rohkem kui ühte kohta (kahekordne kulu). Teiseks peab kellelgi olema võimatu luua kapriisi järgi uusi vara ühikuid (võltsimine). Iga üksus, kes suudab teha ühte neist asjadest, võib varastada süsteemist piiramatu väärtuse.

Nendele probleemidele on tavaline lahendus füüsilised žetoonid, näiteks metallmündid või kindlalt trükitud paber. Need märgid lahendavad triviaalselt topeltkulu probleemi, sest füüsikareeglid (sõna otseses mõttes) takistavad ühe märgi viibimist kahes kohas korraga. Võltsimise probleem lahendatakse, tehes märgi valmistamise äärmiselt keeruliseks. Füüsilistel märkidel on siiski mitmeid puudusi, mis võivad muuta need ebapraktiliseks:

• Puhta kandja varana võib füüsilisi žetoone varastada ilma jälgi või pöördumiseta.
• Suurel arvul või pikkade vahemaade läbimiseks on need aeglased ja kulukad.
• Keerukate ja kulukate on selliste füüsiliste märkide loomine, mida ei saa võltsida.

Neid puudusi saab vältida, kui jätate füüsilised märgid maha ja määrate vara omandiõiguse ümber usaldusväärse vahendaja hallatava pearaamatu mõistes. Varem põhinesid need raamatupidamisdokumendid paberkandjal ja täna kipuvad need töötama tavalistes andmebaasides. Mõlemal juhul teostab vahendaja omandiõiguse üleandmise, muutes pearaamatu sisu, vastuseks autentitud taotlusele. Erinevalt füüsiliste märkidega arveldamisest saab küsitavaid tehinguid kiiresti ja lihtsalt tühistada.

Mis on siis pearaamatute probleem? Lühidalt öeldes kontrolli kontsentreerumine. Nii palju võimu ühte kohta pannes tekitame nii tehnilises kui inimlikus mõttes märkimisväärse julgeolekuprobleemi. Kui keegi väline võib andmebaasi sisse häkkida, saab ta pearaamatut oma äranägemise järgi muuta, varastada teiste rahalisi vahendeid või hävitada selle sisu täielikult. Veel hullem, keegi sees võib pearaamatut rikkuda ja sellist rünnakut on raske avastada ega tõestada. Selle tulemusena peame kõikjal, kus meil on tsentraliseeritud pearaamat, investeerima märkimisväärset aega ja raha selle pearaamatu terviklikkuse säilitamise mehhanismidesse. Ja paljudel juhtudel vajame pidevat kontrollimist, kasutades pearaamatu ja kõigi tehingupoolte vahel partiipõhist lepitust.

Sisestage plokiahel (või „jagatud pearaamat“). See pakub pearaamatute eeliseid, ilma et peaksite keskendumisprobleeme kannatama. Selle asemel käitab iga üksus “sõlme”, millel on pearaamatu koopia, ja hoiab täielikku kontrolli oma varade üle, mis on kaitstud privaatvõtmetega. Tehingud levivad sõlmede vahel peer-to-peer viisil, kusjuures plokiahel tagab konsensuse säilimise. See arhitektuur ei jäta ühtegi keskset rünnakupunkti, mille kaudu häkker või siseringi esindaja võiks pearaamatu sisu rikkuda. Selle tulemusena saab digitaalset finantssüsteemi rakendada kiiremini ja odavamalt, lisades eeliseks reaalajas automaatse leppimise.

Mis on siis negatiivne külg? Nagu varem arutletud, näevad kõik jagatud pearaamatu osalejad kõiki toimuvaid tehinguid, muutes selle kasutuskõlbmatuks olukordades, kus on vaja konfidentsiaalsust. Selle asemel sobivad plokiahelad minu jaoks kerge finantssüsteemid, nimelt need, mille majanduslik panus või osalejate arv on suhteliselt väike. Nendel juhtudel kipub konfidentsiaalsus olema vähem probleem - isegi kui osalejad pööravad üksteise tegemistele suurt tähelepanu, ei õpi nad suurt väärtust. Ja see on täpselt sest panused on madalad, mistõttu eelistame vahendaja loomise vaeva ja kulusid vältida.

Mõned ilmsed näited kergetest finantssüsteemidest on järgmised: ühisrahastus, kinkekaardid, lojaalsuspunktid ja kohalikud valuutad - eriti juhtudel, kui varad on lunastatavad mitmes kohas. Kuid me näeme ka tavapärase finantssektori kasutamise juhtumeid, nagu näiteks võrdõiguslik kauplemine varahaldurite vahel, kes ei ole otseses konkurentsis. Plokiahelaid katsetatakse isegi kui sisemine raamatupidamissüsteemid suurtes organisatsioonides, kus iga osakond või asukoht peab säilitama kontrolli oma vahendite üle. Kõigil neil juhtudel pakub plokiahelate madalam hind ja hõõrdumine kohest kasu, samas kui konfidentsiaalsuse kaotamine ei valmista muret.

Päritolu jälgimine

Siin on teise klassi kasutusjuhtum, mida me MultiChaini kasutajatelt korduvalt kuuleme: kõrge väärtusega esemete päritolu ja liikumise jälgimine kogu tarneahelas, näiteks luksuskaubad, farmaatsiatooted, kosmeetika ja elektroonika. Samamoodi on vaja kriitilisi dokumente, näiteks konossemente või akreditiive. Tarneahelates, mis ulatuvad üle aja ja vahemaa, kannatavad kõik need esemed võltsimise ja varguse käes.

Probleemi saab lahendada plokiahelate abil järgmisel viisil: kui kõrge väärtusega üksus luuakse, väljastab usaldusväärse üksuse vastava digitaalse loa, mis kinnitab selle lähtepunkti autentsust. Seejärel liigutatakse iga kord, kui füüsiline üksus omanikku vahetab, digitaalset žetooni paralleelselt, nii et reaalainete hooldusahelat peegeldab täpselt plokiahelas olev tehingute ahel.

Kui soovite, toimib luba virtuaalse autentsussertifikaadina, mida on palju raskem varastada või võltsida kui paberitükk. Digitaalse märgi saamisel saab füüsilise eseme lõplik saaja, olgu siis pank, turustaja, jaemüüja või klient, kontrollida hooldusahelat kuni päritolupunktini. Tõepoolest, dokumentide, näiteks konossementide puhul saame füüsilise eseme täielikult kaotada.

Kuigi see kõik on mõistlik, märkab nutikas lugeja, et tavaline andmebaas, mida haldab (ütleme) üksuse tootja, suudab sama ülesannet täita. See andmebaas salvestaks iga üksuse praeguse omaniku andmed, aktsepteerides allkirjastatud tehinguid, mis tähistavad iga omaniku muutust, ja vastaks sissetulevatele taotlustele praeguse olukorra kohta.

Miks siis kasutada hoopis plokiahelat? Vastus on, et seda tüüpi rakenduste puhul on hajutatud usaldusel eelis. Sõltumata sellest, kus tsentraliseeritud andmebaasi peetakse, leidub selles kohas inimesi, kellel on võime (ja keda saab altkäemaksu anda) selle sisu rikkuda, märkides võltsitud või varastatud esemed seaduslikuks. Seevastu, kui päritolu jälgitakse tarneahela osalejatele kollektiivselt kuuluvas plokiahelas, ei saa ükski üksus või väike üksuste grupp hooldusõigust rikkuda ja lõppkasutajad saavad rohkem usaldada saadud vastuseid. Boonusena saab erinevaid märke (näiteks mõne kauba ja vastava konossemi kohta) turvaliselt ja vahetada, kasutades kahesuunalist vahetust tagatud madalaimal plokiahela tasemel.

Aga konfidentsiaalsuse probleem? Blokiahelate sobivus tarneahela päritoluks on selle rakenduse lihtsa tehingute mustri õnnelik tulemus. Vastupidiselt finantsturgudele liigub enamik märke päritolust lõpp-punkti ühes suunas, ilma et neid plokiahela osalejate vahel korduvalt edasi-tagasi kaubeldaks. Kui konkurendid teevad omavahel harva tehinguid (nt mänguasjatootja mänguasjatootjale või jaemüüja jaemüüjale), ei saa nad üksteise plokiahela aadresse teada saada ja neid tegeliku identiteediga siduda. Lisaks saab tegevust hõlpsasti jagada mitmeks pearaamatuks, millest igaüks esindab erinevat järjekorda või tüüpi kaupa.

Organisatsioonidevaheline arvepidamine

Mõlemad varasemad kasutusjuhud põhinevad märgistatud varadel, st osalejate vahel üle kantud väärtuse üksuse ahelas esitamisel. Siiski on olemas teine ​​grupp ahela kasutamise juhtumeid, mis pole varadega seotud. Selle asemel toimib kett mehhanismina kollektiivseks registreerimiseks ja notariaalselt tõestamiseks mistahes andmete tüüp, mille tähendus võib olla rahaline või muu.

Üks selline näide on kriitilise suhtluse kontrolljälg kahe või enama organisatsiooni vahel, näiteks tervishoiu- või õigussektoris. Ühtegi rühma organisatsiooni ei saa usaldada selle arhiivi hoidmisega, sest võltsitud või kustutatud teave kahjustaks teisi oluliselt. Sellest hoolimata on vaidluste vältimiseks ülioluline, et kõik nõustuksid arhiivi sisuga.

Selle probleemi lahendamiseks vajame ühist andmebaasi, kuhu kõik kirjed on kirjutatud, kusjuures iga kirjega on kaasas ajatempel ja päritolutõend. Tüüpiline lahendus oleks usaldusväärse vahendaja loomine, kelle ülesanne on dokumentide tsentraalne kogumine ja säilitamine. Kuid plokiahelad pakuvad teistsugust lähenemisviisi, andes organisatsioonidele võimaluse seda arhiivi ühiselt hallata, vältides samal ajal üksikute osalejate (või nende väikeste rühmade) riknemist.

Üks kõige valgustavamaid vestlusi, mis mul viimase kahe aasta jooksul on olnud, oli Michael Mainelli of Z / jeen. Tema ettevõte on 20 aastat ehitanud süsteeme, milles mitu üksust haldavad ühiselt jagatud digitaalset kontrolljälge, kasutades ajatemplit, digitaalallkirju ja ringkontrolli konsensuskava. Nagu ta selgitas nende süsteemide tehnilisi üksikasju, sai selgeks, et need on igas mõttes lubatud plokiahelad. Teisisõnu, blokeerimisahela kasutamisel organisatsioonidevahelise arvestuse pidamiseks pole midagi uut - lihtsalt maailm on lõpuks sellest võimalusest teadlik.

Plokiahelas salvestatud tegelike andmete osas on kolm populaarset võimalust:

• Krüptimata andmed. Seda saab lugeda iga plokiahelas osaleja, pakkudes täielikku ühist läbipaistvust ja vaidluse korral viivitamatut lahendamist.
• Krüptitud andmed. Seda saavad osalejad lugeda ainult vastava dekrüpteerimisvõtmega. Vaidluse korral saab igaüks selle võtme usaldusväärsetele asutustele, näiteks kohtule, avaldada ja kasutada plokiahelat, et tõestada, et teatud osapooled lisasid algsed andmed teatud ajahetkel.
• Räsitud andmed. Ahash”Toimib kompaktse digitaalse sõrmejäljena, mis tähistab pühendumist konkreetsele andmetele, hoides neid andmeid varjatuna. Mõningaid andmeid arvestades saab iga osapool hõlpsalt kinnitada, kas see vastab antud räsi, kuid järeldab andmeid Alates selle räsi on arvutuslikult võimatu. Ainult räsi paigutatakse plokiahelale, kusjuures huvitatud pooled säilitavad algseid andmeid ahelaväliselt, kes saavad selle vaidluse korral avalikustada.

Nagu varem mainitud, on R3CEV Corda toode kasutanud seda kolmandat lähenemist, räsi hoidmine plokiahelas, et kinnitada vastaspoolte vahelisi lepinguid ilma nende sisu paljastamata. Seda meetodit saab kasutada nii arvutiga loetavate lepingukirjelduste kui ka paberdokumentatsiooni sisaldavate PDF-failide jaoks.

Loomulikult ei ole konfidentsiaalsus organisatsioonidevahelise dokumentide pidamise küsimus, sest kogu eesmärk on luua ühine arhiiv, mida kõik osalejad saaksid näha (isegi kui mõned andmed on krüpteeritud või räsitud). Tõepoolest, mõnel juhul võib plokiahel aidata hallata juurdepääsu konfidentsiaalsetele ahelavälistele andmetele, pakkudes digitaalselt allkirjastatud juurdepääsutaotluste muutumatut salvestust. Mõlemal juhul on vahendamise otsene eelis see, et selle kirje pidamiseks ei tohi luua ega usaldada täiendavat üksust.

Mitmeparteiline liitmine

Tehniliselt on see lõplik kasutusklass sarnane eelmisega, kuna mitu osapoolt kirjutavad andmeid ühiselt hallatavale dokumendile. Kuid sel juhul on motivatsioon erinev - ületada infrastruktuurilised raskused, mis on seotud paljude erinevatest allikatest pärineva teabe kombineerimisega.

Kujutage ette kahte panka, kus on klientide identiteedi kontrollimiseks mõeldud sisemised andmebaasid. Mingil hetkel märkavad nad, et neil on palju kliente, nii et nad sõlmivad vastastikuse jagamise kokkuleppe, kus nad vahetavad kontrollitud andmeid, et vältida dubleerimist. Tehniliselt rakendatakse lepingut kasutades standardset ülem-alluv andmete replikatsioon, kus iga pank hoiab teise andmebaasi otse kirjutuskaitstud koopiat ja käivitab paralleelselt päringuid oma andmebaasi ja koopia vastu. Siiamaani on kõik korras.

Kujutage nüüd ette, et need kaks panka kutsuvad veel kolm osalema selles jagamisringis. Kõigil viiel pangal on oma põhiandmebaas koos teiste kirjutuskaitsega 5 koopiaga. 4 põhimeistri ja 5 koopiaga on meil kokku 20 andmebaasi eksemplari. Kuigi see on teostatav, kulutab see iga panga IT-osakonnas märkimisväärset aega ja ressursse.

Kiiresti edasi punkti, kus 20 panka jagavad sel viisil teavet, ja me vaatame kokku 400 andmebaasi eksemplari. 100 panga puhul jõuame 10,000 XNUMX eksemplarini. Üldiselt, kui kõik osapooled jagavad teavet üksteisega, kasvab andmebaasi eksemplaride koguarv koos osalejate arvu ruuduga. Mingil hetkel selles protsessis süsteem kindlasti laguneb.

Mis on lahendus? Üks ilmne võimalus on, et kõik pangad esitavad oma andmed usaldusväärsele vahendajale, kelle ülesandeks on koondada need andmed ühte põhiandmebaasi. Seejärel võiks iga pank seda andmebaasi eemalt pärida või oma nelja seina vahel kohalikku kirjutuskaitstud koopiat käitada. Kuigi sellel lähenemisel pole midagi valesti, pakuvad plokiahelad odavamat alternatiivi, milles jagatud andmebaasi haldavad otse seda kasutavad pangad. Plokiahelad toovad ka lisakasu koondamine ja failover kogu süsteemile.

Oluline on selgitada, et plokiahel ei tegutse lihtsalt hajutatud andmebaasina Cassandra or Mõelge uuesti läbi. Erinevalt neist süsteemidest rakendab iga plokiahelasõlm reegleid, mis takistavad ühel osalisel teise lisatud andmeid muuta või kustutada. Tõepoolest, selles osas on endiselt teatavat segadust - ühe hiljuti välja antud blockchaini platvormi saab murda üks valesti tegutsev sõlm. Igal juhul teeb hea platvorm hõlpsaks ka tuhandete sõlmedega võrkude haldamise, liitudes ja lahkudes soovi korral, kui neile antakse vastavad õigused.

Kuigi ma olen natuke skeptiline blokeerimisahelate ja Asjade Internet, Ma arvan, et siin võib peituda tugev selline sünergia. Muidugi oleks iga “asi” plokiahela täieliku koopia kohalikuks salvestamiseks liiga väike. Pigem edastaks see andmeid kandvad tehingud plokiahela sõlmede hajutatud võrku, kes koondaks selle kõik koos edasiseks otsimiseks ja analüüsimiseks.

Järeldus: plokiahelad rahanduses

Alustasin seda tükki, seades kahtluse alla finantssektori plokiahelate jaoks ette nähtud esialgse kasutuse juhtumi, nimelt makse- ja vahetustehingute hulgimüügi. Kuigi ma usun, et see järeldus on muutumas tavaliseks tarkuseks (ühega) tähelepanuväärne erand), ei tähenda see, et plokiahelatel pole selles valdkonnas muid rakendusi. Tegelikult näeme kõigi nelja eespool nimetatud kasutusjuhu klassi puhul pankade ja muude finantsasutuste jaoks selgeid rakendusi. Need on vastavalt: väikesed kaubandusringkonnad, lähtekoht kaubanduse finantseerimiseks, kahepoolne lepingute notariaalne kinnitamine ja AML / KYC andmete koondamine.

Võti mõistmiseks on see, et arhitektuuriliselt meie neli kasutusklassi ei kuulu konkreetse rahastada ning on võrdselt olulised ka teistes sektorites, nagu kindlustus, tervishoid, turustamine, tootmine ja IT. Tõepoolest, eraviisilisi plokiahelaid tuleks kaaluda igas olukorras, kus kaks või enam organisatsiooni vajavad ühist vaadet reaalsusele ja see vaade ei pärine ühest allikast. Neil juhtudel pakuvad plokiahelad alternatiivi usaldusväärse vahendaja vajadusele, mis aitab märkimisväärselt kokku hoida vaeva ja kulusid.

Palun postitage kõik kommentaarid LinkedIn.

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