Mõttetu plokiahela projekti vältimine

Kuidas teha kindlaks, kas olete leidnud tõelise plokiahela kasutusjuhtumi

Plokiahelad on liialdatud. Seal ma ütlesin seda. Alates SIBOS et Raha20 / 20 lugude katmiseks The Economist ja Euromoney, kõik näivad ronivat plokiahela vaguni pardale. Ja kahtlemata, nagu ka teised selles ruumis tegutsejad, näeme kiiresti kasvavat hulka ettevõtteid, kes ehitavad kontseptsiooni tõendeid meie platvormil ja/või paludes meie abi.

Noore idufirmana võiks arvata, et oleme üle kuu. Kindlasti on nüüd aeg koguda palju raha ja ehitada üles see suure jõudlusega järgmise põlvkonna plokiahela platvorm, mille oleme juba kavandanud. Mida kuradit me ootame?

Ma ütlen teile, mida. Ootame, et saaksime selgema arusaama plokiahelate asukohast tõesti lisaväärtust ettevõtte IT-s. Näete, suur osa nendest sissetulevatest projektidest on olemas plokiahelatega pole üldse midagi pistmist. See toimib järgmiselt. Suur ettevõte kuuleb, et plokiahelad on järgmine suur asi. Suur ettevõte leiab sisemiselt mõned inimesed, kes on teemast huvitatud. Suur ettevõte annab neile eelarve ja käsib neil teha midagi plokiahelat. Varsti nad koputavad meie uksele, lehvitavad dollaritähti ja küsivad us aidata neid mõtle välja kasutusjuhtum. Ütle mis nüüd?

Mis puutub nendesse, kellel on projekt meeles, siis milles probleem on? Paljudel juhtudel saab projekti suurepäraselt ellu viia kasutades tavalist relatsiooniandmebaasi. Teate, suured rauast behemotid meeldivad Oraakel ja SQL Servervõi avatuma mõtlemisega inimestele, MySQL ja postgres. Lubage mul alustada asjade paikapanemisest:

Kui tänapäevased relatsiooniandmebaasid vastavad teie nõudmistele, oleks plokiahela kasutamine hull.

Miks? Sest sellistel toodetel nagu Oracle ja MySQL on taga aastakümnete pikkune arendustegevus. Neid on juurutatud miljonites serverites, mis käitavad triljoneid päringuid. Need sisaldavad mõnda planeedi kõige põhjalikumalt testitud, silutud ja optimeeritud koodi, mis töötleb tuhandeid tehinguid sekundis ilma higistamata.

Ja kuidas on lood plokiahelatega? Noh, meie toode oli üks esimesi, mis turule tuli ja on olnud saadaval täpselt 5 kuud, paari tuhande allalaadimisega. Tegelikult on see äärmiselt stabiilne, sest me ehitasime selle välja Bitcoin Core, tarkvara, mis toidab bitcoini. Kuid isegi nii, kogu see tootekategooria on endiselt mähkmetes.

Kas ma siis ütlen, et plokiahelad on kasutud? Absoluutselt mitte. Kuid enne selle särava plokiahela projektiga alustamist peab teil olema sellest väga selge ettekujutus miks te plokiahelat kasutate. On hunnik tingimusi, mis tuleb täita. Ja kui nad ei ole, peaksite minema tagasi joonistuslaua juurde. Võib-olla saate projekti paremini määratleda. Või võib-olla säästate kõigi aega ja raha, sest te ei vaja plokiahelat.

1. Andmebaas

Siin on esimene reegel. Plokiahelad on tehnoloogia, mille jaoks jagatud andmebaasid. Seega peate kõigepealt teadma, miks te kasutate andmebaasi, mille all pean silmas struktureeritud teabehoidlat. See võib olla traditsiooniline relatsioonandmebaasis, mis sisaldab ühte või mitut tabelilaadset tabelit. Või võib see olla trendikam NoSQL sort, mis toimib pigem failisüsteemi või sõnaraamatuna. (Teoreetilisel tasandil on NoSQL-i andmebaasid niikuinii vaid relatsiooniandmebaaside alamhulk.)

Finantsvarade pearaamatut saab loomulikult väljendada andmebaasitabelina, kus iga rida tähistab ühte varatüüpi, mis kuulub ühele konkreetsele olemile. Igal real on kolm veergu, mis sisaldavad: (a) omaniku identifikaatorit, näiteks kontonumbrit, (b) vara tüübi identifikaatorit (nt „USD” või „AAPL”) ja (c) selle vara kogust, mida see vara hoiab. omanik.

Andmebaase muudetakse „tehingute” kaudu, mis kujutavad endast andmebaasi muudatuste kogumit, mis tuleb tervikuna aktsepteerida või tagasi lükata. Näiteks varareskontra puhul kujutab makset ühelt kasutajalt teisele tehing, mis lahutab sobiva koguse ühelt realt ja lisab selle teisele.

2. Mitu kirjanikku

See on lihtne. Plokiahelad on tehnoloogia, mille jaoks mitme kirjutajaga andmebaasid. Teisisõnu peab andmebaasi muutvaid tehinguid genereerima rohkem kui üks üksus. Kas sa tead, kes need kirjanikud on?

Enamikul juhtudel käivitavad kirjutajad ka "sõlmed", mis hoiavad andmebaasi koopiat ja edastavad tehingud teistele sõlmedele. peer-to-peer mood. Kuid tehinguid võivad luua ka kasutajad, kes ise sõlme ei käita. Mõelge näiteks maksesüsteemile, mida haldab ühiselt väike pankade rühm, kuid millel on miljoneid mobiilseadmeid kasutavaid lõppkasutajaid, kes suhtlevad ainult oma panga süsteemidega.

3. Usalduse puudumine

Ja nüüd kolmas reegel. Kui andmebaasi kirjutab mitu olemit, peab ka teatud määral olema umbusaldus nende üksuste vahel. Teisisõnu, plokiahelad on tehnoloogia mitme mitteusaldusväärse kirjutajaga andmebaasid.

Võib arvata, et usaldamatus tekib ainult erinevate organisatsioonide vahel, nagu näiteks turul kauplevad pangad või tarneahelas osalevad ettevõtted. Aga see võib ka eksisteerida ühe suure organisatsiooni sees, näiteks osakondade vahel või erinevates riikides toimuvate tegevuste vahel.

Mida ma umbusaldamise all täpsemalt mõtlen? Pean silmas seda, et üks kasutaja ei ole nõus laskma teisel muuta andmebaasi kirjeid, mida ta omab. Samamoodi, kui tegemist on andmebaasi sisu lugemisega, ei aktsepteeri üks kasutaja teise kasutaja teatatud „tõde” evangeeliumina, kuna igaühel on erinevad majanduslikud või poliitilised stiimulid.

4. Vahendamine

Seega on probleemiks, nagu seni määratletud, mitme mitteusaldusväärse kirjutajaga andmebaasi lubamine. Ja sellele probleemile on juba tuntud lahendus: usaldusväärne vahendaja. See tähendab, keegi, keda kõik kirjanikud usaldavad, isegi kui nad üksteist täielikult ei usalda. Tõepoolest, maailm on täis seda laadi andmebaase, nagu näiteks pangakontode pearaamat. Sinu pank kontrollib andmebaasi ning tagab, et iga tehing on kehtiv ja kliendi poolt, kelle raha see liigutab, volitatud. Ükskõik kui viisakalt te ka seda küsite, ei luba teie pank teil kunagi oma andmebaasi otse muuta.

Plokiahelad eemaldavad vajaduse usaldusväärsete vahendajate järele, lubades mitme mitteusaldusväärse kirjutajaga andmebaasid, mida saab otse muuta. Ükski keskväravapidaja ei pea tehinguid kontrollima ja nende allikat autentima. Selle asemel laiendatakse tehingu määratlust nii, et see hõlmaks volituse ja kehtivuse tõendit. Tehingud võivad seega olla sõltumatult kontrollitud ja töödeldud iga sõlme poolt mis säilitab andmebaasi koopia.

Kuid küsimus, mida peate esitama, on järgmine: Kas soovite või vajate seda vahendust? Kas teie kasutusjuhtumit arvestades on midagi valesti selles, et keskne osapool peab autoriteetset andmebaasi ja tegutseb tehingute väravavahina? Head põhjused eelistada plokiahelal põhinevat andmebaasi usaldusväärsele vahendajale võivad hõlmata madalamaid kulusid, kiiremaid tehinguid, automaatset leppimine, uus regulatsioon või lihtsalt suutmatus leida sobivat vahendajat.

5. Tehingu interaktsioon

Seega on plokiahelad mõttekad andmebaaside jaoks, mida jagavad mitmed kirjutajad, kes üksteist täielikult ei usalda ja muudavad seda andmebaasi otse. Aga sellest siiski ei piisa. Plokiahelad säravad tõeliselt seal, kus neid on tehingute vaheline interaktsioon nende kirjanike loodud.

Mida ma mõtlen interaktsiooni all? Täielikus tähenduses tähendab see, et erinevate kirjanike loodud tehingud sõltuvad sageli üksteisest. Näiteks oletame, et Alice saadab osa raha Bobile ja seejärel saadab Bob osa Charlie'le. Sel juhul sõltub Bobi tehing Alice'i tehingust ja Bobi tehingut pole võimalik kontrollida ilma Alice'i tehingut esmalt kontrollimata. Selle sõltuvuse tõttu kuuluvad tehingud loomulikult a-sse kokku ühtne jagatud andmebaas.

Seda edasi võttes on plokiahelate üks tore omadus see, et tehinguid saab luua mitme kirjaniku koostöös, ilma et kumbki osapool ennast riskiks. See on see, mis võimaldab kohaletoimetamine versus makse arveldamine toimub ohutult plokiahela kaudu, ilma usaldusväärset vahendajat nõudmata.

Hea juhtumi võib pidada ka olukordadeks, kus erinevate kirjutajate tehingud on omavahel ristkorrelatsioonis, isegi kui need jäävad sõltumatuks. Üks näide võib olla jagatud identiteedi andmebaas, milles mitu olemit kinnitavad tarbijate identiteedi erinevaid aspekte. Kuigi iga selline sertifikaat on eraldiseisev, pakub plokiahel kasulikku võimalust kõike ühtsel viisil koondada.

6. Sea reeglid paika

See pole tegelikult tingimus, vaid pigem eelmiste punktide vältimatu tagajärg. Kui meil on andmebaasi, mida on otse muutnud mitu kirjutajat ja need kirjutajad ei usalda üksteist täielikult, peab andmebaas sisaldama manustatud reegleid tehtavate tehingute piiramine.

Need reeglid on põhimõtteliselt erinevad piiranguid mis ilmuvad traditsioonilistes andmebaasides, kuna need on seotud teisenduste legitiimsust mitte andmebaasi olek konkreetsel ajahetkel. Iga võrgu sõlm kontrollib iga tehingut nende reeglite järgi ja need, mis ebaõnnestuvad, lükatakse tagasi ja neid ei edastata.

Varade pearaamatud sisaldavad seda tüüpi reeglite lihtsat näidet, et vältida tehinguid, mis loovad varasid tühjalt kohalt. Reegel ütleb, et pearaamatu iga vara koguhulk peab olema sama enne ja pärast iga tehingut.

7. Valige oma validaatorid

Siiani oleme kirjeldanud hajutatud andmebaasi, milles tehingud võivad pärineda paljudest kohtadest, levida sõlmede vahel peer-to-peer viisil ja neid kontrollib iga sõlm iseseisvalt. Kuhu siis tuleb "plokiahel"? Noh, plokiahela ülesanne on olla autoriteetne lõplik tehingute päevik, mille sisuga nõustuvad kõik sõlmed.

Miks me seda logi vajame? Esiteks võimaldab see äsja lisatud sõlmedel arvutada andmebaasi sisu nullist, ilma et oleks vaja teist sõlme usaldada. Teiseks käsitleb see võimalust, et mõned sõlmed võivad süsteemi seisaku või sidehäire tõttu mõne tehingu vahele jätta. Ilma tehingulogita erineks see ühe sõlme andmebaas teistest, mis kahjustaks jagatud andmebaasi eesmärki.

Kolmandaks on võimalik, et kaks tehingut on vastuolus, nii et aktsepteeritakse ainult ühte. Klassikaline näide on a topeltkulu mille puhul saadetakse sama vara kahele erinevale adressaadile. Peer-to-peer andmebaasis, millel puudub keskasutus, võivad sõlmedel olla erinevad arvamused selle kohta, millist tehingut aktsepteerida, kuna objektiivset õiget vastust pole. Nõudes tehingute "kinnitamist" plokiahelas, tagame, et kõik sõlmed lähenevad samale otsusele.

Lõpuks sisse Ethereum-stiilis plokiahelad, täpsed tellimine tehingute arvul on ülioluline roll, sest iga tehing saab seda teha mõjutada seda, mis juhtub igas järgnevas. Sel juhul määratleb plokiahel autoriteetse kronoloogia, ilma milleta ei saa tehinguid üldse töödelda.

Plokiahel on sõna otseses mõttes plokkide ahel, milles iga plokk sisaldab tehingute komplekti, mis kinnitatakse rühmana. Kuid kes vastutab igasse plokki tehtavate tehingute valimise eest? Seda tüüpi „privaatses plokiahelas“, mis sobib ettevõtete rakendustele, on vastuseks suletud rühm validaatoreid („kaevureid“, kes allkirjastavad digitaalselt nende loodud plokid). See valgesse nimekirja lisamine on kombineeritud mingi hajutatud konsensusskeemiga, et vältida kontrollijate vähemust ahela üle kontrolli haaramast. Näiteks MultiChain kasutab skeemi nimega kaevandamise mitmekesisus, milles lubatud kaevurid töötavad a ümmargune röövel teatud leebusega, et võimaldada mittetoimivaid sõlme.

Olenemata sellest, millist konsensusskeemi kasutatakse, on valideerivatel sõlmedel palju vähem jõudu kui traditsioonilise tsentraliseeritud andmebaasi omanikul. Validaatorid ei saa võltsida tehinguid ega muuta andmebaasi selle reegleid rikkudes. Varade pearaamatus tähendab see, et nad ei saa kulutada teiste inimeste raha ega muuta esindatavate varade koguhulka. Sellegipoolest on endiselt kaks võimalust, kuidas valideerijad saavad andmebaasi sisu põhjendamatult mõjutada:

• Tehingute tsensuur. Kui piisavalt palju valideerijaid pahatahtlikult kokku lepivad, võivad nad takistada konkreetse tehingu kinnitamist plokiahelas, jättes selle jäädavalt teadmatusse.
• Erapoolik konfliktide lahendamine. Kui kaks tehingut on vastuolus, otsustab järgmise ploki loov valideerija, milline tehing plokiahelas kinnitatakse, mistõttu teine ​​lükatakse tagasi. Õiglane valik oleks tehing, mida nähti esimesena, kuid valideerijad saavad teha valiku muude tegurite põhjal, ilma seda paljastamata.

Nende probleemide tõttu peab plokiahelapõhise andmebaasi juurutamisel olema sellest selge ettekujutus kes on teie valideerijad ja miks te neid usaldate, kollektiivselt, kui mitte üksi. Olenevalt kasutusjuhtumist võib validaatoriteks olla: (a) üks või mitu sõlme, mida juhib üks organisatsioon, (b) ahelat haldavate organisatsioonide tuumikrühm või (c) võrgu iga sõlm.

8. Tagastage oma vara

Kui olete nii kaugele jõudnud, olete võib-olla märganud, et kaldun nimetama plokiahelaid jagatud andmebaasideks, mitte tavalisemateks "jagatud pearaamatuteks". Miks? Kuna tehnoloogiana saab plokiahelaid rakendada probleemidele, mis on kaugel varade omandiõiguse jälgimisest. Iga andmebaasi, millel on mitu mitteusaldusväärset kirjutajat, saab rakendada plokiahela kaudu, ilma et oleks vaja keskset vahendajat. Näiteks ühiskalendrid, wiki-stiilis koostöö- ja arutelufoorumid.

Seda arvestades tundub praegu, et plokiahelad pakuvad huvi peamiselt neile, kes jälgivad finantsvarade liikumist ja vahetust. Mul on selleks kaks põhjust: (a) finantssektor reageerib (tagantjärele mõeldes väikesele) krüptovaluutade, nagu bitcoin, ohule ja (b) varade pearaamat on kõige lihtsam ja loomulikum näide jagatud andmebaasist. vastastikku sõltuvad tehingud, mille on loonud mitu mitteusaldavat üksust.

Kui soovite kasutada plokiahelat varade pearaamatuna, peate vastama veel ühele olulisele küsimusele: milline on ümber teisaldatavate varade olemus? Selle all ei pea ma silmas ainult sularaha, võlakirju või konossemente, kuigi loomulikult on see ka oluline. Küsimus on pigem: Kes seisab plokiahelas esindatud varade taga? Kui andmebaasis on kirjas, et mulle kuulub midagi 10 ühikut, siis kes lubab mul need 10 ühikut nõuda reaalses maailmas? Kelle poole ma kaevan, kui ma ei saa plokiahelas kirjutatut traditsioonilisteks füüsilisteks varadeks teisendada? (Vaata seda varaleping näiteks.)

Vastus sõltub muidugi kasutusjuhtumist. Rahaliste varade puhul võib ette kujutada, et depoopangad võtavad sularaha vastu traditsioonilisel kujul ja krediteerivad seejärel hoiustajate kontosid plokiahela toega hajutatud pearaamatus. Kaubanduse rahastamises tagaksid akreditiivid ja konossemendid vastavalt importija pank ja laevandusettevõte. Ja tulevikus võime ette kujutada aega, mil esmane emiteerimine ettevõtete võlakirjade kogumine toimub otse plokiahelas ettevõtte poolt, kes soovib raha koguda.

Järeldus

Nagu sissejuhatuses mainisin, kui teie projekt ei täida iga neist tingimustest, ei tohiks te plokiahelat kasutada. Ühegi esimese viie puudumisel peaksite kaaluma ühte järgmistest: (a) tavapärane failisalvestus, (b) tsentraliseeritud andmebaas, (c) ülem-alluv. andmebaasi replikatsioonvõi (d) mitu andmebaasi, kuhu kasutajad saavad pääseda tellima.

Ja kui täidate esimesed viis, on veel tööd teha. Peate suutma väljendada oma rakenduse reegleid tehingute osas, mida andmebaas võimaldab. Peate olema kindel selles, keda saate valideerijatena usaldada ja kuidas määratlete hajutatud konsensuse. Ja lõpuks, kui soovite luua jagatud pearaamatut, peate teadma, kes toetab selle pearaamatu varasid.

Kas said kõik vastused? Õnnitleme, teil on tõeline plokiahela kasutusjuht. Ja me tahaksime sinust kuulda.

Palun postitage kõik kommentaarid LinkedIn. Vaadake ka seda järeltegevust: Neli ehtsat plokiahela kasutamise juhtumit.