Bitcoin vs blockchain arutelu lõpetamine

Kas ilma krüptovaluutata on blockchainil mingit väärtust?

Arutelu on kestnud juba mõnda aega, kuid viimase kuu jooksul on aset leidnud tõsine tõus. Küsitakse järgmist:

Kas krüptorahata plokiahelas on väärtust? Ja kas neid “märkideta jagatud raamatuid” saab üldse nimetada plokiahelateks?

Nii et ma olen lugenud Bailey artikkel, vaatasin Timi video, loe see Nasdaqi postitus, järgnes Richardile iga sõnaja isegi mul oli oma heatujuline arutelu (vt kommentaare) vastaspoole Chris DeRose'iga. Nii palju kuuma õhku.

Üks asi, mis Chrisil hästi läheb, on see küsimuseni: kas plokiahel on majanduslik või infotehnoloogiline uuendus? See tähendab, et kui blockchains on puhtalt majanduslik uuendus, pole mõtet blokeerida ilma krüptovaluutadeta. Lubage mul öelda oma seisukoht alguses:

Bitcoini plokiahel oli ühtaegu majanduslik ja arvutiteaduse uuendus.

Luban siia lisada ka „innovatsiooni” olemasolevate tehnikate uus kombinatsioon, mitte millegi üle, millel pole pretsedenti. See määratlus võimaldab Internetis käsitleda uuendust, kuigi see tegi midagi enamat kui hüperteksti ühendamine mõne olemasoleva Interneti-protokolli keerdumisega. Kui soovite kasutada rangemat innovatsiooni määratlust, olge minu külaline, kuid teid üllatab, kui vähe tõelisi "uuendusi" on alles. Parafraseerides Õpetaja, päikese all on vähe uut.

Täpsustuseks väidan seda Ilma sümbolita blokeeringud teenivad eesmärki, kuid see on a erinev eesmärk võrreldes algse bitcoini plokiahelaga. Krüptopead naeravad märgivabade plokiahelate üle, sest nad ei suuda töökindluse kaudu tagada tsensuuriresistentsust ja detsentraliseeritud turvalisust. Fintechi pead naeravad avalike plokiahelate üle, sest need on aeglased, kallid ja traditsiooniliseks rahanduseks sobimatud. Noh, jätke kõigi naerma, sest ma usun, et teil on mõlemal õigus.

Ma väidan, et märgivabad plokiahelad on kasulikud detsentraliseeritud andmebaaside sünkroonis hoidmiseks, isegi ühes organisatsioonis, milles valitseb täielik usaldus. Ja siis näeme, milliseid muid funktsioone plokiahelad pakuvad, mis muudavad need konsensuse saavutamiseks sobivaks konkreetsed tehinguliigid organisatsioonide vahel, kus usaldus on vaid piiratud ja ebatäiuslik.

Kahjuks peate argumendi järgimiseks minuga tutvuma bitcoini tehingumudeli, andmebaasi multiversiooni samaaegsuse kontrolli (MVCC) ja mitme peamise andmebaasi replikatsiooni konfliktide lahendamise probleemiga. Annan endast parima, et inglise keelest kinni pidada, kuid siiski on see tehniline värk ja seda pole võimalik vältida.

Bitcoini tehingumudel

Bitcoini tehingumudel on lihtne, kuid võimas. Igal bitcoini tehingul on komplekt sisendeid ja väljundeid. Iga sisend “kulutab” ühe eelmise tehingu väljundi. Kogu tehingu sisendites olev bitcoin voolab sellesse tehingusse ja jaotub selle väljundite vahel vastavalt sisestatud kogustele. Sel moel moodustavad tehingud mitmepoolse ühendatud ahela, mis lõpeb mündibaasi tehingutega, milles luuakse uusi bitcoine.

Bitcoinil on hunnik lisareegleid, mida jõustab iga võrgusõlm:

• Iga tehingu sisend peab tõestama, et tal on õigus kulutada varasem väljund, millega see on ühendatud. Seda õigust piiravad tingimused, mis on kodeeritud varasemasse väljundisse.
• Tehingu sisendites peab olema piisavalt kogu bitcoini, et katta väljundites kirjutatud kogusummat. Ainsad erandid on mündipõhised tehingud, millega luuakse uued valuutaühikud.
• Iga väljundit saab kulutada ainult üks kord, teisisõnu saab seda ühendada ainult ühe sisendiga ühes järgnevas tehingus.

Selle viimase reegli tõttu nõuab võrk mehhanismi konsensuse saavutamiseks selles osas, millised tehingud kehtivad, ja seda teeb plokiahel. Täpsemalt:

Kui kaks tehingut üritavad kulutada sama toodangut, aktsepteeritakse lõpuks ainult ühte neist tehingutest. Plokiahel toimib ühtse mehhanismina nende konfliktide avastamiseks ja vältimiseks kogu võrgus.

Plokiahel on üles ehitatud kui seotud plokkide seeria, milles iga plokk sisaldab tehingute kogumit, mis ei ole omavahel ega eelmiste plokkidega vastuolus, alates esimesest 2009. aastal loodud plokist. Teoreetiliselt võiks kett sisaldada rida üksikuid tehinguid, kuid rühmitades tehingud plokkideks, saame hulga efektiivsusi, mis muudavad skeemi praktilisemaks.

Mis on krüptovaluuta eesmärk selles kõiges? See taandub küsimusele, kes otsustab ahela moodustavate plokkide üle. Bitcoin on detsentraliseeritud ja tal pole volitusi, mis seda otsust teha saaks, seega peab ta leidma mõne muu viisi konsensuse saavutamiseks.

Me võiksime kasutada demokraatlikku lähenemisviisi, kus võrgu sõlmed hääletavad blokkide üle ja enamus võidab. Kahjuks, nagu iga Interneti-küsitlus võib näidata, pole esindusdemokraatia veebis võimalik kellegi teisena esinemise probleemi (tuntud ka kui Sybili rünnak). Üks inimene võib üle võtta miljoni arvuti ja otsustada, kuidas nad hääletavad, haarates seeläbi kontrolli võrgu konsensuse üle. Keegi teine ​​isegi ei tea, et see on juhtunud.

Selle lahendamiseks muudab bitcoin tahtlikult ploki lisamise ahelasse protsessi kaudu, mida nimetatakse kaevandamiseks. Bloki loomiseks peate lahendama raske, kuid mõttetu matemaatilise ülesande, mis nõuab palju arvutamist (ja seega ka elektrit ja raha). Teil on vaja ka õnne, kuna võistlete paljude teiste plokkkaevandajatega üle kogu maailma. Võimsama kaevandusarvuti ostmisega ei saa kaua edasi minna, sest võrk korrigeerib probleemi raskusi regulaarselt, et hoida ühtlast globaalset kiirust üks plokk 10 minuti kohta.

Kui ploki loomine on nii keeruline ja kulukas, siis miks keegi peaks vaeva nägema? Vastus on plokktasus. Bloki edukas kaevur kontrollib mündibaasi tehingut, mis annab neile 25 bitcoini (see summa väheneb poole võrra iga nelja aasta tagant). Nad saavad neid bitcoine vabal turul müüa 7,000 dollari (tänase kursi järgi) eest, maksta ära elektriarve ja loodetavasti tasuda kasumit. Kaevurid koguvad tehingutega seotud lõivudest ka natuke lisatasu, ehkki praegu on neil tasudel väike roll.

Niisiis tekitab Bitcoin töökindluse kaudu üksmeele ja bitcoini peade argumendi tuum on järgmine: Ilma krüptovaluutata ei saa kuidagi stimuleerida plokkide detsentraliseeritud kaevandamist. Seetõttu pole mingit võimalust kindlustada avatud plokiahel jäljendamisrünnakute vastu. Seetõttu saavad kõik võrgu konsensuse monopoliseerida ja kogu asja kasutuks muuta. Ma ei hakka selle vastu vaidlema.

Multiversioni kokkulangevuskontroll

Vahepeal tahan rääkida millestki, mis võib tunduda täiesti sõltumatu.

Andmebaas on struktureeritud teabe hoidla, mis on rühmitatud tabelitaolisteks üksusteks, mida nimetatakse tabeliteks. Sellise tabeli lihtne näide on pangakontode loend, kus iga rida sisaldab konto numbrit koos selle konto saldoga. Oletame, et teie konto alustab päeva saldoga 900 dollarit. Täna on kavandatud automaatne hüpoteegi maksmine 750 dollarit ja peate pangaautomaadist välja võtma ka 400 dollarit. Kahjuks pole teil arvelduskrediiti võimalust, nii et üks neist toimingutest on loodud ebaõnnestumiseks.

Hüpoteekmaksete ja sularahaautomaatide väljavõtmise protsessid toimivad eraldi süsteemides, mis mõlemad pääsevad sellele ühtse konto andmebaasile juurde. Oletame, et iga protsess töötab nii, et loete oma konto saldot, kontrollite, kas see on toimingu jaoks piisav, käivitate selle toimingu, kontrollite, kas toiming on lõpule viidud, arvutage uus saldo ja kirjutage see lõpuks andmebaasi.

Niikaua kui teie hüpoteegi makse ja sularahaautomaadi väljavõtmine ei kattu, töötab see loogika hästi. Esimene toiming viiakse edukalt läbi ja teine ​​katkestatakse, kuna teie kontol pole piisavalt raha. Sõltuvalt tellimusest saate pangast vihase telefonikõne või sularahaautomaadi ekraanil ebaviisakas sõnumi.

Aga mis juhtub, kui kaks protsessi juhtuvad algama üheaegselt? Sellisel juhul loevad kumbki teie konto saldot ja peavad seda jätkamiseks piisavaks. Kui hüpoteegi makse on lõpetatud, arvutatakse teie uus saldo 150 dollarini ja kirjutatakse andmebaasi. Kui sularahaautomaadist loobumine on lõpule viidud, kirjutatakse samamoodi ka teie uus saldo 500 dollarit. Üks neist kirjutamisoperatsioonidest alistab teise ja sõltuvalt teie õnnest saab pangalt 750 või 400 dollari suuruse boonuse. Kahtlemata õpite varsti oma sularahaautomaadi külastusi hüpoteegi päevaks ajastama.

Loomulikult ei juhtu seda reaalsuses, kuna nn andmebaasitehnoloogia on nn samaaegsuse kontroll. Samaaegsuse kontrollimine hoiab meie andmed (eriti rahalised) mõistlikud ja turvalised ning seda on mitmel kujul. Kuid kõik jagavad põhimõtet, et andmebaasitoimingud on rühmitatud tehinguteks, mida käsitletakse aatomiliselt, mis tähendab, et need õnnestuvad või ebaõnnestuvad tervikuna. Samaaegsus säilitab järjepidevuse, lukustades või külmutades andmebaasi osad, kui need on ühe tehingu ajal kasutusel, et takistada teiste tehingute toimimist sama teabe vastuolulisel viisil.

Kui meil poleks vaja tehinguid paralleelselt käivitada, võiksime kogu andmebaasi kogu tehingu ajaks lukustada. Kuid see pole enamikus reaalsetes rakendustes praktiline. Hea samaaegsuse kontrolliskeem võimaldab paralleelseid toiminguid, lukustades võimalikult vähe andmeid võimalikult lühikeseks ajaks. Ülaltoodud näites lukustatakse ainult teie kontole vastav andmebaasirida ja ainult sekundi murdosa jooksul, mil toimus viimane kontroll ja mahaarvamine. Paralleelselt toimiv konfliktne tehing peaks lihtsalt ootama, kuni see lukk vabastatakse.

Ühte populaarset samaaegsuse juhtimise tehnikat nimetatakse multiversioonide samaaegsuse kontrollvõi lühidalt MVCC. MVCC-s näeb iga tehing andmete järjepidevat ülevaadet teatud ajahetkel, isegi kui osa neist andmetest on värskendatud teise samaaegse tehingu abil. Seda hetktõmmise isoleerimine kinnisvara tagab näiteks, et väljavõte, mis näitab meie kogu saldot mitmel kontol, on alati õige, isegi kui mõni raha liigub ühelt kontolt teisele. Üks tehing mõjutab teise tehingu andmeid ainult siis, kui teine ​​algab pärast kõigi esimese muudatuste edukat rakendamist.

Stseenide taga töötab MVCC, lubades korraga mitut rea versiooni säilitada koos ajatempliga, mis tähistab iga versiooni viimase muudatuse kuupäeva. MVCC-s andmebaasirea muutmine tähistab selle rea praeguse versiooni kustutamiseks, rakendades samal ajal modifikatsiooni a-le selle rea koopia ajakohastatud ajatempliga. Andmebaasi salvestuskihi vaatevinklist ei saa sellist asja muuta, kui rida paigas on. Iga tehing teab täpselt, millal see algas, ja näeb ainult nende ridade versioone, mille ajatempel on enne seda aega. Ridade vanad versioonid saab salvestusruumist eemaldada, kui pole käimasolevaid tehinguid, mis võivad vajada neile juurdepääsu.

Oluliselt meie eesmärkidel väldib MVCC konflikte kirjutamisoperatsioonide vahel. Täpsemalt:

Kui kaks tehingut üritavad sama rea ​​versiooni kustutada, aktsepteeritakse lõpuks ainult ühte neist tehingutest. Mitme versiooni samaaegsuse kontroll toimib ühtse mehhanismina nende konfliktide tuvastamiseks ja ennetamiseks andmebaasis.

Helistada kellasid? Seal on veel üks taust, mida peame arutama.

Mitme Master-andmebaasi replikatsioon

Räägime nüüd andmebaasi replikatsioonist, kus andmebaas eksisteerib mitmes eksemplaris. Andmebaasi paljundamiseks on mitu head põhjust, näiteks:

• Usaldusväärsuse suurendamiseks, nii et kui üks andmebaasi eksemplar on kadunud (nt ketta rikke tõttu), saame koheselt üle minna teisele eksemplarile.
• Läbilaskevõime suurendamiseks, kui toimingute maht ületab ühe andmebaasiserveri mahtu.
• Lamineerimise vähendamiseks, nii et Singapuri kontoris töötavad protsessid ei pea Torontos asuvas andmebaasis vastuseid ootama.

Kui tegemist on lugemine andmebaaside andmeid, on replikatsioon ideaalne tehnika, kuna kõik repliigid sisaldavad sama teavet. Kirjutamistoimingute puhul lähevad asjad siiski kleepuvaks, sest peame otsustama, kus neid kirjutamistoiminguid teostatakse ja kuidas neid andmebaasi teistele koopiatele üle kantakse.

Kõige tavalisem vastus on master-slave replikatsiooni kasutamine, kus autoriteetseks peetakse ühte andmebaasi (“master”). Kõik muudatused andmetes tehakse eranditult põhiseadmel ja levivad seejärel tehingulogi kaudu kõikidesse teistesse "alluvate" andmebaasidesse. See hoiab kõik andmebaasi koopiad (enam-vähem) koheselt sünkroonis.

Kahjuks, kui kirjutamistoimingud on sagedased, viib isand-ori replikatsioon meid tagasi selle probleemi juurde, mille replikatsioon oli mõeldud lahendama. Põhiandmebaasist saab usaldusväärsuse, läbilaskevõime ja latentsuse kitsaskoht, kuna iga kirjutamistoiming viiakse läbi sellega üksi.

Keerulisemat strateegiat nimetatakse mitme põhi replikatsiooniks, kus kirjutamist saab teha ükskõik millisele andmebaasi koopiale, mitte ühele masterile. Sel juhul jagavad koopiad värskendusi omavahel peer-to-peer viisil, et sünkroonis püsida.

See kõlab teoreetiliselt lihtsalt, kuid mitme masti replikatsioon toob kaasa uue probleemi, kuna võivad tekkida konfliktid. Mis siis, kui andmebaasi kaks eksemplari värskendavad sama rida korraga, ja siis proovige neid värskendusi omavahel vahetada? Mõlemad andmebaasid märkavad, et vastuoluline värskendus on toimunud, ja peavad nende konfliktide lahendamiseks rakendama kokkulepitud strateegiat. Ja siin asjad saavad päris keeruline - vaadake dokumente MySQL, SQL Server or Oraakel mõned näited konfliktide lahendamise strateegiatest. (Ma eiran sünkroonset või nn innukat multi-master replikatsiooni, kus kõik koopiad peavad enne toimumist pühenduma kirjutamistoimingule, sest see pöördub iga andmebaasi koopia kitsaskohta.)

Nii et kogu see taust viib siia:

Kas poleks tore, kui me oleksime saanud jaotada mitmeversioonilise samaaegsuse juhtimise, vältimaks konflikte, mis tekivad mitme juhi replikatsioonis?

Jah, ma kujutan ette, et see oleks tõesti väga tore. Ja ma usun, et just seda teevad plokiahelad.

Plokiahelad jaotatud MVCC-na

Kopeerime paar lauset, mille ma kirjutasin ülalpool rasvases kirjas:

Kui kahe tehinguga üritatakse kulutama seesama väljund, siis lõpuks aktsepteeritakse ainult ühte neist tehingutest. Plokiahel toimib ühtse mehhanismina nende konfliktide avastamiseks ja ennetamiseks kogu võrgus.

Kui kahe tehinguga üritatakse kustutama seesama rea versioon, siis aktsepteeritakse lõpuks ainult ühte neist tehingutest. Multiversioni kokkulangevuskontroll toimib ühtse mehhanismina nende konfliktide avastamiseks ja ennetamiseks andmebaasis.

Need laused on identsed, välja arvatud paksud terminid. Nii et siin on see, mida ma väidan:

Plokiahel pakub hajutatud MVCC-d (koos mõne lisakella ja -vilega).

Täpsustame võrdlust veidi edasi. Plokiahela sõlme perspektiivist moodustab praegune kulutamata bitcoini tehingute väljundite komplekt andmebaasi, milles iga rida on üks kulutamata väljund. See sarnaneb meie kirjeldatud pangakontode andmebaasiga, väikse erinevusega, et iga konto saldo saab jagada mitmele reale, millest igaüks on tähistatud sama kontonumbriga.

Bitcoini tehing kulutab ühe või mitu neist väljunditest ja loob selle tulemusena ühe või mitu uut väljundit. See on täpselt nagu andmebaasi tehing, mis kustutab ühe või mitu rea versiooni ja loob selle tulemusel ühe või mitu uut rida (tuletage meelde, et MVCC-s pole sellist asja, nagu rida oma kohal muuta). Bitcoini plokiahel tagab, et ühte väljundit ei saa kulutada rohkem kui ühe tehingu abil. See on samaväärne selle tagamisega, et ühte rida versiooni ei saa kustutada rohkem kui ühe andmebaasitehinguga.

Nüüd, enne kui meid köidab, ei väida ma, et plokiahelad on suurepärane üldotstarbeline tehnoloogia andmebaaside hajutatud sünkroonimiseks täielikult usaldusväärses keskkonnas. On palju muid tehnoloogiaid nagu paxos, Parv ja Kahefaasiline kohustus mis täidavad seda tööd väga kenasti. Kuid ma usun, et plokiahelatel on magus koht, mida saab iseloomustada kui rakendusi, kus:

• Võime leppida lühikese viivitusega selle vahel, millal tehing tõenäoliselt aktsepteeritakse ja millal see kindlasti aktsepteeritakse. (See viivitus võib olla bitcoinide puhul pigem sekundite kui 10 minuti küsimus.)
• Vastuolulisi tehinguid ei tohiks kunagi juhtuda, kui kõik on ausad ja nende süsteemid töötavad korralikult.
• Iga tehing muudab korraga vaid mõnda rida (vastasel juhul on meie plokiahela tehingutel koormamatu arv sisendeid).
• Iga andmebaasirea suurus on üsna väike (jällegi, et vältida meie plokiahela tehingute suurust).

Kõik need kriteeriumid on rahaliste rakenduste poolt täidetud. Finantsmaailm on juba harjunud viivitustega (kuni 3 päeva!) Tehingu sooritamise ja selle lõpliku arveldamise vahel. Konfliktide ennetamise osas on pettuste avastamiseks olemas lepingud ja määrused ning tagajärjed võivad olla tõsised. Ja iga tehinguga seotud andmemaht on üsna väike - mõelgem ülaltoodud pangakonto näitele.

Siiani olen kõik tõestanud, et plokiahelad on veel üks hajutatud andmebaaside sünkroonimismehhanism. Suur vau. Asjad muutuvad tõeliselt huvitavaks ainult siis, kui kaalume plokiahelate pakutavaid lisafunktsioone.

Plokiahelad väljaspool MVCC-d

Bitcoini tehing teeb palju enamat kui lihtsalt osutab mõnele varasemale tehingu väljundile ja loob nende asemele mõned uued. Isegi kõige lihtsam bitcoini tehing teenib kahte täiendavat eesmärki.

Esiteks sisaldavad kehtivate tehingute reeglid osa meie konto andmebaasi rakendusloogikast. Tuletame meelde, et tehingu sisendites sisalduva bitcoini üldkogus peab katma väljundites sisalduva üldkoguse. Andmebaasirakenduste loogikasse tõlgituna on see reegel, mis ütleb, et andmebaasi tehingutel (välja arvatud mündibaasid) ei ole lubatud suurendada andmebaasi bitcoini üldkogust. Selline piirang ületab tavalise andmebaasi piire salvestatud protseduurid sest sellest ei saa mingil juhul mööda hiilida.

Teiseks tuletage meelde, et iga bitcoini tehingu väljund kodeerib tingimusi, mille korral seda saab kulutada. Regulaarsete bitcoini väljundite korral põhineb see tingimus avaliku võtme krüptograafial. Avalik aadress on manustatud väljundi "skripti" sisse, nii et seda saab kulutada ainult sellele avalikule aadressile vastava privaatvõtme abil. Kui peame seda väljundit andmebaasireaks, on meil andmebaas, millel on rea kohta õigused, mis põhinevad avaliku võtme krüptograafial. Lisaks esitab iga tehing avalikult auditeeritava tõendi selle kohta, et selle looja (te) l oli õigus oma varasemad read kustutada / muuta. See (ma usun) on tõeline uudsus andmebaaside tehnoloogias.

Ja jälle juhtub, et mõlemad funktsioonid on finantsrakenduste jaoks uskumatult kasulikud. Meile meeldib see, et meie andmebaas tagab võimalikult madalal tasemel, et raha ei saa luua õhust. Ja meile meeldib, kui meil on vaieldamatu kontrolljälg, mis näitab, et igale tehingule andis loa nende ülekantud vahendite omanik. As arutatakse siin üksikasjalikult, võib meile meeldida ka turvaliste aatomi peer-to-peer vahetustehingute sooritamine (tarne versus maksmine rahanduses - rääkimata), teadmata isegi oma vastaspoole identiteeti.

Nii et kus on märk?

Mõistagi pole see juhus, sest bitcoin ise on ilus peer-to-peer finantsrakendus. Siiski ei sõltu ükski plokiahela ülaltoodud omadustest märgist üldse. Kui muudame oma "andmebaasi" skeemi nii, et iga rida võib kujutada mitut vara, mitte plokiahela emakeelset valuutat, siis võime sellest valuutast täielikult vabaneda. See jätab meile plokiahela kui võimaluse saavutada konsensust ja turvalisust võrdõiguslike finantsrakenduste puhul mis tahes liiki vara.

Ainult üks väike küsimus: Kes kaevandab selle konsensuse saavutamiseks? Bitcoinis peavad anonüümsed kaevurid sooritama kalleid kasutuid arvutusi ning neid motiveerivad plokiahela emakeelses vääringus või märgis vääringustatud plokkhüved (ja tehingutasud). Kas meil on muid võimalusi?

Tuleb välja, et teeme. Meil võib olla suletud nimekiri lubatud kaevuritest, kes identifitseerivad end oma loodud plokkidele alla kirjutades. Reeglid hajutatud konsensuse kohta (või nn kaevandamise mitmekesisus), nagu me seda nimetame MultiCin) pakuvad teist võimalust blokeerimisahela vähemuste kontrolli vältimiseks, seni, kuni saate nõustuda, et kaevurid on eelnevalt heaks kiidetud. Muidugi ei ole see bitcoini puhul aktsepteeritav, sest üks osa on lubada anonüümset kaevandamist, seega pole võimalust tehinguid tsentraliseerida. Aga kui meil oleks näiteks väga reguleeritud finantssüsteem, kus bitcoini mudelit ei olnud võimalik rakendada, võiksime ikkagi aktsepteerida eelnevalt heakskiidetud kaevurite nimekirja? Kui meil oleks neist piisavalt ja levitaksime neid piisavalt hästi institutsioonide vahel ning oleksime kõigiga seaduslikke lepinguid sõlminud, kas nad siis tõenäoliselt puksivad ja õõnestavad võrku, millest nad sõltuvad, maandavad nad nad siis vangi?

Epiloog

Loodan, et olen näidanud, et märkideta plokiahelatel on mõned kasulikud rakendused, isegi kui need erinevad bitcoini plokiahelast väga palju. Sellest hoolimata jääb üks küsimus:

Kas need luba omavad, märgideta jagatud pearaamatusüsteemid on tõesti nime “blockchain” väärt?

Lühike vastus on: keda see huvitab? Sõnade tähenduse üle tasub harva vaielda, sest seda on pole õiget vastust.

Kuid natuke sügavamale minnes ütleme, et nõustun eeldusega, et bitcoini plokiahel on arhetüüpne plokiahel. Sel juhul peaksime tegelikult küsima:

Kas need jagatud pearaamatud on piisavalt sarnased bitcoiniga, et väärida nime "blockchain"?

Minu enda isiklik vaade on jah. Kuna neil on tohutu hulk tehnilisi sarnasusi, isegi kui nad erinevad lubade mudeli ja majanduslike stiimulite poolest. Ja mis kõige tähtsam, sest mõlemad genereerivad hajutatud andmebaasis üksuse a kaudu plokkide kett.

Täname, et lugemine.

Võite jälgige mind siin Twitteris. Vaata ka: Kohaletoimetamine versus maksmine plokiahelas.

Siin on veel paar tükki, mida tasub sellel teemal lugeda Piotr Piasecki ja Kaevas Campbelli.