Nutikas lepingu tutvustamine: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Koodi plokiahelasse sisestamiseks on rohkem kui üks viis

Enamikus plokiahelate teemalistes aruteludes ei lähe kaua aega, kui „nutikate lepingute” mõiste kerkib esile. Populaarse kujutlusvõime kohaselt automatiseerivad nutikad lepingud osapooltevahelise suhtluse teostamist, ilma et oleks vaja usaldusväärset vahendajat. Väljendades õigussuhteid pigem koodiga kui sõnadega, lubavad need tehingud toimuda vahetult ja vigadeta, olenemata sellest, kas need on tahtlikud või mitte.

Tehnilisest vaatenurgast on tark leping midagi spetsiifilisemat: arvutikood, mis elab plokiahelas ja määratleb selle ahela tehingute reeglid. See kirjeldus kõlab piisavalt lihtsalt, kuid selle taga on palju erinevusi selles, kuidas neid reegleid väljendatakse, täidetakse ja kinnitatakse. Uue rakenduse jaoks plokiahela platvormi valimisel tekib küsimus "Kas see platvorm toetab nutikaid lepinguid?" pole õige küsida. Selle asemel peame küsima: "Millist tüüpi nutikaid lepinguid see platvorm toetab?"

Selles artiklis on minu eesmärk uurida mõningaid peamisi erinevusi arukate lepinguliste lähenemisviiside ja nende poolt pakutavate kompromisside vahel. Teen seda, vaadates nelja populaarset ettevõtte plokiahela platvormi, mis toetavad mõnda kohandatud ahelasisest koodi. Esiteks IBM-i oma Hyperledger kangas, mis nimetab oma lepinguid "ahelakoodiks". Teiseks meie MultiChain platvorm, mis tutvustab nutikad filtrid versioonis 2.0. Kolmandaks Ethereum (ja see on lubatud Kvoorum ja urg spin-offid), mis populariseeris nutika lepingu nime. Ja lõpuks, R3 Corda, mis viitab oma tehingutes "lepingutele". Vaatamata erinevale terminoloogiale viitavad kõik need lõppkokkuvõttes samale asjale – rakendusepõhisele koodile, mis määratleb ahela reeglid.

Enne edasiminekut peaksin lugejat hoiatama, et suur osa järgmisest sisust on tehnilist laadi ja eeldab üldist programmeerimise ja andmebaasi kontseptsioonide tundmist. Hea või halva puhul ei saa seda vältida – üksikasjadesse süvenemata on võimatu teha teadlikku otsust selle kohta, kas kasutada konkreetse projekti jaoks plokiahelat ja (kui jah) millist tüüpi plokiahelat kasutada.

Blockchaini põhitõed

Alustame mõnest kontekstist. Kujutage ette rakendust, mida jagavad mitmed organisatsioonid ja mis põhineb aluseks oleval andmebaasil. Traditsioonilises tsentraliseeritud arhitektuuris hostib ja haldab seda andmebaasi üks osapool, mida kõik osalejad usaldavad, isegi kui nad üksteist ei usalda. Andmebaasi muutvaid tehinguid algatavad ainult selle keskosa süsteemide rakendused, sageli vastuseks osalejatelt saadud sõnumitele. Andmebaas teeb lihtsalt seda, mida talle öeldakse, kuna rakendust usaldatakse vaikimisi, et see saadaks talle ainult mõistlikke tehinguid.

Plokiahelad pakuvad alternatiivset viisi jagatud andmebaasi haldamiseks ilma usaldusväärse vahendajata. Plokiahelas käitab iga osaleja "sõlme", ​​mis hoiab andmebaasi koopiat ja töötleb iseseisvalt seda muutvaid tehinguid. Osalejad tuvastatakse avalike võtmete või "aadresside" abil, millest igaühel on vastav privaatvõti, mida teab ainult identiteedi omanik. Kuigi tehinguid saab luua mis tahes sõlm, allkirjastatakse need nende algataja privaatvõtmega digitaalselt, et tõestada nende päritolu.

Sõlmed ühenduvad üksteisega peer-to-peer viisil, levitades kiiresti tehinguid ja "plokke", milles need on ajatempliga ja kogu võrgus kinnitatud. Plokiahel ise on sõna otseses mõttes nende plokkide ahel, mis moodustab iga ajaloolise tehingu järjestatud logi. "Konsensusalgoritmi" kasutatakse tagamaks, et kõik sõlmed jõuaksid plokiahela sisus kokkuleppele, ilma et oleks vaja tsentraliseeritud juhtimist. (Pange tähele, et osa sellest kirjeldusest ei kehti Corda kohta, kus igal sõlmel on ainult osaline koopia andmebaasist ja globaalset plokiahel puudub. Räägime sellest lähemalt hiljem.)

Põhimõtteliselt saab iga jagatud andmebaasirakendust üles ehitada, kasutades selle tuumaks plokiahelat. Kuid see tekitab mitmeid tehnilisi väljakutseid, mida tsentraliseeritud stsenaariumi puhul ei eksisteeri:

• Tehingureeglid. Kui mõni osaleja saab otse andmebaasi muuta, siis kuidas tagame, et ta järgib rakenduse reegleid? Mis takistab ühel kasutajal andmebaasi sisu omakasupüüdlikult rikkumast?
• Determinism. Kui need reeglid on määratletud, rakendavad mitmed sõlmed neid mitu korda oma andmebaasi koopia tehingute töötlemisel. Kuidas tagada, et iga sõlm saaks täpselt sama tulemuse?
• Konfliktide ennetamine. Kuidas toimida ilma keskse koordineerimiseta kahe tehinguga, mis mõlemad järgivad rakenduse reegleid, kuid on siiski üksteisega vastuolus? Konfliktid võivad tuleneda tahtlikust katsest süsteemi mängida või olla ebaõnne ja ajastuse süütu tagajärg.

Kuhu siis tulevad nutikad lepingud, nutikad filtrid ja kettkood? Nende põhieesmärk on töötada plokiahela aluseks oleva infrastruktuuriga, et neid väljakutseid lahendada. Nutikad lepingud on rakenduskoodi detsentraliseeritud ekvivalent – ​​ühes keskses kohas töötamise asemel töötavad need plokiahela mitmes sõlmes, luues või kinnitades tehinguid, mis muudavad selle andmebaasi sisu.

Alustame tehingureeglitega, mis on esimene neist väljakutsetest, ja vaatame, kuidas need väljenduvad vastavalt Fabricus, MultiChainis, Ethereumis ja Cordas.

Tehingureeglid

Tehingureeglid täidavad plokiahela toega andmebaasides kindlat funktsiooni – piiravad muundumised mida saab teha selle andmebaasi olekus. See on vajalik, kuna plokiahela tehinguid võivad algatada kõik selle osalejad ja need osalejad ei usalda üksteist piisavalt, et võimaldada neil andmebaasi oma äranägemise järgi muuta.

Vaatame kahte näidet selle kohta, miks tehingureegleid vaja on. Esiteks kujutage ette plokiahelat, mis on loodud selles osalejate avaldatud PDF-dokumentide koondamiseks ja ajatempli tegemiseks. Sel juhul ei tohiks kellelgi olla õigust dokumente eemaldada ega muuta, kuna see kahjustaks kogu süsteemi eesmärki – dokumentide püsivust. Teiseks kaaluge plokiahelat, mis esindab jagatud finantsraamatut, mis jälgib oma kasutajate saldosid. Me ei saa lubada osalejal oma saldot meelevaldselt paisutada või teistelt raha ära võtta.

Sisendid ja väljundid

Meie plokiahela platvormid tuginevad tehingureeglite väljendamiseks kahele laiaulatuslikule lähenemisviisile. Esimest, mida ma nimetan "sisend-väljundmudeliks", kasutatakse MultiChainis ja Cordas. Siin loetlevad tehingud selgesõnaliselt andmebaasi read või "olekud", mille nad kustutavad ja loovad, moodustades vastavalt "sisendite" ja "väljundite" komplekti. Rea muutmist väljendatakse samaväärse toiminguna selle rea kustutamiseks ja selle asemele uue loomiseks.

Kuna andmebaasi read kustutatakse ainult sisendites ja luuakse ainult väljundites, peab iga sisend "kulutama" eelmise tehingu väljundi. Andmebaasi praegune olek on määratletud kui "kasutamata tehinguväljundite" või "UTXO-de" kogum, st väljundid varasematest tehingutest, mida pole veel kasutatud. Tehingud võivad sisaldada ka lisateavet, mida nimetatakse "metaandmeteks", "käskudeks" või "manusteks", mis ei muutu andmebaasi osaks, kuid aitavad määratleda nende tähendust või eesmärki.

Arvestades neid kolme sisendite, väljundite ja metaandmete komplekti, määrab tehingu kehtivuse MultiChainis või Cordas mingi kood, mis võib nendes komplektides teha suvalisi arvutusi. See kood võib tehingu kinnitada või tagastada veateate koos vastava selgitusega. Sisend-väljund mudelit võib pidada automatiseeritud "inspektoriks", kellel on kontrollnimekiri, mis tagab, et tehingud järgivad kõiki reegleid. Kui tehing mõni neist kontrollidest ebaõnnestub, lükkavad kõik võrgu sõlmed selle automaatselt tagasi.

Tuleb märkida, et vaatamata sisend-väljundmudeli jagamisele rakendavad MultiChain ja Corda seda väga erinevalt. MultiChainis võivad väljundid sisaldada varasid ja/või andmeid JSON-vormingus, teksti- või binaarvormingus. Reeglid on määratletud "tehingufiltrites" või "voofiltrites", mille saab seadistada kontrollima kõiki tehinguid või ainult neid, mis hõlmavad teatud varasid või andmerühmitusi. Seevastu Corda väljundi "olekut" esindab objekt Java või Kotlini programmeerimiskeeles määratletud andmeväljadega. Corda reeglid on määratletud "lepingutes", mis on lisatud konkreetsetele olekutele, ja osariigi lepingut kohaldatakse ainult tehingutele, mis sisaldavad seda olekut oma sisendites või väljundites. See on seotud Cordaga ebatavaline nähtavuse mudel, milles tehinguid näevad ainult nende vastaspooled või need, kelle hilisemaid tehinguid need mõjutavad.

Lepingud ja sõnumid

Teist lähenemist, mida ma nimetan "lepingu-sõnumi mudeliks", kasutatakse Hyperledger Fabricus ja Ethereumis. Siin saab plokiahelas luua mitu "nutikat lepingut" või "ahelakoodi" ning igaühel neist on oma andmebaas ja seotud kood. Lepingu andmebaasi saab muuta ainult selle koodiga, mitte otse plokiahela tehingutega. See disainimuster on sarnane koodi ja andmete kapseldamisele objektorienteeritud programmeerimises.

Selle mudeli puhul algab plokiahela tehing lepingule saadetava sõnumina, millel on mõned valikulised parameetrid või andmed. Lepingu kood käivitatakse vastusena sõnumile ja parameetritele ning võib selle reaktsiooni osana vabalt lugeda ja kirjutada oma andmebaasi. Lepingud võivad saata sõnumeid ka teistele lepingutele, kuid ei pääse otse üksteise andmebaasidele. Relatsiooniandmebaaside keeles toimivad lepingud kui jõustunud "salvestatud protseduurid", kus kogu juurdepääs andmebaasile toimub mingi eelmääratletud koodi kaudu.

Nii Fabric kui ka Quorum, Ethereumi variatsioon, muudavad selle pildi keerulisemaks, võimaldades võrgul määratleda mitu "kanalit" või "privaatolekut". Eesmärk on leevendada plokiahela konfidentsiaalsuse probleemi, luues eraldi keskkondi, millest igaüks on nähtav ainult teatud osalejate alarühmale. Kuigi see kõlab teoreetiliselt paljulubavalt, on tegelikkuses iga kanali või erariigi lepingud ja andmed teistest eraldatud. Sellest tulenevalt on need keskkonnad nutikate lepingute mõttes võrdväärsed eraldiseisvate plokiahelatega.

Näidisreeglid

Vaatame, kuidas nende kahe mudeliga ühe varaga finantsreskontra tehingureegleid rakendada. Meie pearaamatu andmebaasi igal real on kaks veergu, mis sisaldavad omaniku aadressi ja omandis oleva vara kogust. Sisend-väljund mudelis peavad tehingud vastama kahele tingimusele:

1. Varade koguhulk tehingu väljundis peab ühtima selle sisendite koguarvuga. See takistab kasutajatel raha meelevaldselt luua või kustutada.
2. Iga tehingu peab allkirjastama iga selle sisendi omanik. See takistab kasutajatel üksteise raha ilma loata kulutamast.

Kokkuvõttes on need kaks tingimust kõik, mida on vaja lihtsa, kuid elujõulise finantssüsteemi loomiseks.

Leping-sõnum mudelis toetab vara leping “saada makse” teadet, millel on kolm parameetrit: saatja aadress, saaja aadress ja saadetav kogus. Vastuseks täidab leping järgmist nelja sammu:

1. Veenduge, et saatja oleks tehingule alla kirjutanud.
2. Kontrollige, kas saatjal on piisavalt raha.
3. Saatja realt võta nõutud kogus maha.
4. Lisage see kogus adressaadi reale.

Kui kumbki kahe esimese etapi kontrollidest ebaõnnestub, leping katkeb ja makset ei tehta.

Seega on nii sisend-väljund kui ka lepingu-sõnumi mudelid tõhusad viisid tehingureeglite määratlemiseks ja jagatud andmebaasi turvaliseks hoidmiseks. Tõepoolest, teoreetilisel tasandil saab kõiki neid mudeleid kasutada teise simuleerimiseks. Praktikas aga sõltub kõige sobivam mudel ehitatavast rakendusest. Kas iga tehing mõjutab vähe või palju teavet? Kas me peame suutma tagada tehingute sõltumatuse? Kas igal andmel on selge omanik või on mõni globaalne olek, mida jagada?

Siinkohal ei ole meil võimalik uurida, kuidas vastused peaksid mõjutama nende kahe mudeli vahelist valikut. Aga üldiseks juhiseks, et uut plokiahela rakendust arendades tasub proovida väljendada selle tehingureegleid mõlemas vormis ja vaadata, kumb sobib loomulikumalt. Erinevused väljenduvad järgmistes aspektides: (a) programmeerimise lihtsus, (b) salvestusnõuded ja läbilaskevõime ning (c) konfliktide tuvastamise kiirus. Sellest viimasest numbrist räägime pikemalt hiljem.

Sisseehitatud reeglid

Mis puutub tehingureeglitesse, siis on üks viis, mille poolest MultiChain erineb Fabricust, Ethereumist ja Cordast. Erinevalt nendest teistest platvormidest on MultiChainil mitu sisseehitatud abstraktsiooni, mis pakuvad mõningaid põhilisi ehitusplokke plokiahela juhitud rakenduste jaoks ilma nõudes arendajatel kirjutada oma kood. Need abstraktsioonid hõlmavad kolme valdkonda, mida tavaliselt vajatakse: (a) dünaamilised load, (b) ülekantavad varad ja (c) andmesalvestus.

Näiteks MultiChain haldab õigusi võrguga ühenduse loomiseks, tehingute saatmiseks ja vastuvõtmiseks, varade või voogude loomiseks või teiste kasutajate õiguste kontrollimiseks. Turvaliselt ja aatomiliselt saab välja anda, üle kanda, pensionile viia või vahetada mitut asendatavat vara. Ahelas saab luua mis tahes arvu „voogusid”, et avaldada, indekseerida ja hankida ahelasiseseid või ahelaväliseid andmeid JSON-, teksti- või binaarvormingus. Kõik nende abstraktsioonide tehingureeglid on kohe saadaval.

Rakendust MultiChainis arendades on võimalik seda sisseehitatud funktsiooni eirata ja tehingureegleid väljendada ainult nutikate filtrite abil. Nutikad filtrid on aga loodud töötama koos nende sisseehitatud abstraktsioonidega, võimaldades nende vaikekäitumist piiratud kohandatud viisidel. Näiteks võivad teatud tegevuste luba kontrollida konkreetsed administraatorid, mitte vaikekäitumist, mida iga administraator teeb. Teatud varade üleandmine võib olla ajaliselt piiratud või nõuda teatud summa ületamisel täiendavat heakskiitu. Konkreetse voo andmeid saab valideerida tagamaks, et need koosnevad ainult nõutavate väljade ja väärtustega JSON-struktuuridest.

Kõigil neil juhtudel loovad nutikad filtrid tehingute kinnitamiseks lisanõudeid, kuid ei tee seda kõrvaldama Sisseehitatud lihtsad reeglid. See võib aidata lahendada plokiahela rakenduste üht peamist väljakutset: tõsiasja, et mõne ahelasisese koodi viga võib viia katastroofiliste tagajärgedeni. Oleme näinud selle probleemi kohta lõputult näiteid avalikus Ethereumi plokiahelas, millest kõige kuulsam on DAO hääbumine ja Pariteedi multisignature vead. Laiemad küsitlused on leidnud Ethereumi nutikatest lepingutest suure hulga levinumaid turvaauke, mis võimaldavad ründajatel varastada või külmutada teiste inimeste raha.

Muidugi võivad MultiChaini nutikad filtrid sisaldada ka vigu, kuid nende tagajärjed on piiratumad. Näiteks sisseehitatud varareeglid takistavad ühel kasutajal võõra raha kulutamast või kogemata oma raha kaduma panemast, olenemata sellest, millist muud loogikat nutikas filter sisaldab. Kui nutikas filtris leitakse viga, saab selle deaktiveerida ja asendada parandatud versiooniga, samal ajal kui pearaamatu põhiline terviklikkus on kaitstud. Filosoofiliselt on MultiChain lähemal traditsioonilistele andmebaasiarhitektuuridele, kus andmebaasiplatvorm pakub mitmeid sisseehitatud abstraktsioone, nagu veerud, tabelid, indeksid ja piirangud. Võimsamad funktsioonid, nagu päästikud ja salvestatud protseduurid, saavad soovi korral rakenduste arendajad üles kodeerida, kui neid tegelikult vaja läheb.

Tehingureeglid	Kangas	MultiCin	Ethereum	Corda
MUDEL	Leping – sõnum	Sisend väljund	Leping – sõnum	Sisend väljund
Sisseehitatud	mitte ükski	Load + varad + vood	mitte ükski	mitte ükski

Determinism

Liigume edasi oma showdowni järgmise osa juurde. Pole tähtis, millise lähenemisviisi me valime, plokiahela rakenduse kohandatud tehingureeglid väljendatakse rakenduste arendajate kirjutatud arvutikoodina. Ja erinevalt tsentraliseeritud rakendustest käivitatakse seda koodi iga tehingu jaoks rohkem kui üks kord ja rohkem kui ühes kohas. Selle põhjuseks on asjaolu, et mitu plokiahela sõlme, mis kuuluvad erinevatele osalejatele, peavad igaüks selle tehingu ise kontrollima ja/või teostama.

See korduv ja üleliigne koodi täitmine toob kaasa uue nõude, mida tsentraliseeritud rakendustes harva kohtab: determinism. Arvutamise kontekstis tähendab determinism seda, et koodilõik annab samade parameetrite jaoks alati sama vastuse, olenemata sellest, kus ja millal seda käivitatakse. See on plokiahelaga suhtleva koodi jaoks ülioluline, sest ilma determinismita võib selle ahela sõlmede vaheline konsensus katastroofiliselt laguneda.

Vaatame, kuidas see praktikas välja näeb, kõigepealt sisend-väljund mudelis. Kui kahel sõlmel on tehingu kehtivuse kohta erinev arvamus, siis üks aktsepteerib seda tehingut sisaldavat plokki ja teine ​​mitte. Kuna iga plokk lingib selgesõnaliselt tagasi eelmise plokiga, loob see võrgus püsiva "hargi", kus üks või mitu sõlme ei aktsepteeri sellest hetkest alates enamuse arvamust kogu plokiahela sisu kohta. Vähemuses olevad sõlmed katkestatakse andmebaasi arenevast olekust ja nad ei saa enam rakendust tõhusalt kasutada.

Nüüd vaatame, mis juhtub, kui konsensus lepingu-sõnumi mudelis katkeb. Kui kahel sõlmel on erinev arvamus selle kohta, kuidas leping peaks konkreetsele sõnumile vastama, võib see põhjustada erinevusi nende andmebaaside sisus. See võib omakorda mõjutada lepingu reageerimist tulevastele sõnumitele, sealhulgas sõnumitele, mida see saadab teistele lepingutele. Lõpptulemus on kasvav lahknevus erinevate sõlmede vaate vahel andmebaasi olekust. (Ethereumi plokkide olekujuurväli tagab, et kõik lepingute vastuste erinevused viivad koheselt täielikult katastroofilise plokiahela kahvlini, selle asemel et riskida mõneks ajaks varjatuks jäämisega.)

Mittedeterminismi allikad

Seega on plokiahela koodi mittedeterminism selgelt probleem. Aga kui arvutamise põhielemendid, nagu aritmeetika, on deterministlikud, siis mille pärast peame muretsema? Selgub, päris mitu asja:

• Ilmselgelt juhuslike arvude generaatorid, kuna definitsiooni järgi on need loodud iga kord erineva tulemuse saamiseks.
• Praeguse kellaaja kontrollimine, kuna sõlmed ei töötle tehinguid täpselt samal ajal ja igal juhul võivad nende kellad olla sünkroonist väljas. (Ikka on võimalik rakendada ajast sõltuvaid reegleid, viidates ajatemplitele plokiahelas endas.)
• Päringute tegemine välistest ressurssidest, nagu Internet, kettafailid või muud arvutis töötavad programmid. Ei saa garanteerida, et need ressursid annavad alati sama vastuse ja võivad muutuda kättesaamatuks.
• Mitme koodilõigu käitamine paralleelselt "lõime", kuna see viib "rassitingimusteni", kus protsesside lõpu järjekorda ei saa ennustada.
• Mis tahes ujukomaarvutuste tegemine, mis võib erinevate arvutiprotsessorite arhitektuuride puhul anda isegi väga erinevaid vastuseid.

Meie neli plokiahela platvormi kasutavad nende lõksude vältimiseks mitmeid erinevaid lähenemisviise.

Deterministlik täitmine

Alustame Ethereumist, kuna selle lähenemine on kõige "puhtam". Ethereumi lepingud on väljendatud eriotstarbelises vormingus nimega "Ethereumi baitkood", mida täidab Ethereumi virtuaalmasin (EVM). Programmeerijad ei kirjuta baitkoodi otse, vaid pigem genereerivad või “kompileerivad” selle JavaScripti sarnasest programmeerimiskeelest nimega Solidity. (Varem olid saadaval ka teised keeled, kuid need on nüüdseks aegunud.) Determinismi tagab asjaolu, et Solidity ja Ethereum baitkood ei suuda kodeerida mittedeterministlikke tehteid – nii lihtne see ongi.

MultiChaini filtrid ja Corda lepingud valivad teistsuguse lähenemisviisi, kohandades olemasolevaid programmeerimiskeeli ja käituskeskkondi. MultiChain kasutab Google'is töötavat JavaScripti V8 mootor, mis moodustab ka Chrome'i brauseri ja Node.js platvormi tuuma, kuid mille mittedeterminismi allikad on keelatud. Samamoodi kasutab Corda Java või Kotlin, mis mõlemad on kompileeritud "Java baitkoodiks", mis käivitatakse Java virtuaalmasinas (JVM). Praegu kasutab Corda Oracle'i standardset mittedeterministlikku JVM-i, kuid töö on käimas, et integreerida deterministlik versioon. Seni peavad Corda lepingute arendajad hoolitsema selle eest, et mitte lubada oma koodis ebamäärasust.

Kuidas on Ethereumi purism võrreldav MultiChaini ja Corda evolutsioonilise lähenemisviisiga? Ethereumi peamine eelis on riskide minimeerimine – otstarbeks ehitatud virtuaalmasin sisaldab vähem tõenäoliselt tahtmatut mittedeterminismi allikat. Kuigi mis tahes sellist kõrvalekallet saab tarkvaravärskendusega parandada, häiriks see kõiki kette, kellel pole õnne sellega kokku puutuda. Ethereumi probleem seisneb aga selles, et Solidity ja EVM moodustavad programmeerimiskeelte ja käituskeskkondade laiemas kontekstis pisikese ja tärkava ökosüsteemi. Võrdluseks on JavaScript ja Java kaks parimat keelt Githubis, töötab miljarditel digitaalseadmetel ja nende käitusaeg on aastakümnete jooksul optimeeritud. Arvatavasti see on põhjus, miks avalik Ethereumi plokiahel kaalub üleminekut sellele eWASM, areneva WebAssembly standardi deterministlik kahvel.

Determinism kinnitamise teel

Mis puutub determinismi, siis Hyperledger Fabric kasutab täiesti teistsugust lähenemist. Kui Fabricu sõlm soovib saata sõnumi mõnele ahelkoodile, saadab ta selle sõnumi esmalt mõnele kinnitaja sõlmele. Kõik need sõlmed täidavad ahelkoodi iseseisvalt, moodustades sõnumite kohta arvamuse mõju selle kettkoodi andmebaasis. Need arvamused saadetakse kliendile tagasi koos digiallkirjaga, mis kujutab endast ametlikku kinnitust. Kui klient saab kavandatud tulemuse kohta piisavalt kinnitusi, loob ta neid kinnitusi sisaldava tehingu ja edastab selle ahelasse kaasamiseks.

Determinismi tagamiseks on igal ahelkoodil „kinnituspoliitika”, mis määratleb täpselt, millisel tasemel heakskiitu on vaja tehingute kehtivuseks. Näiteks võib ühe ahelkoodi poliitika sätestada, et kinnitusi nõutakse vähemalt pooltelt plokiahela sõlmedelt. Teine võib nõuda ühe kolmest usaldusväärsest osapoolest kinnitust. Mõlemal juhul saab iga sõlm iseseisvalt kontrollida, kas vajalikud kinnitused saadi.

Erinevuse selgitamiseks põhineb determinism enamikus plokiahela platvormides küsimusel: "Mis on selle koodi nende andmete alusel käitamise tulemus?" – ja me peame olema täiesti kindlad, et iga sõlm vastab sellele küsimusele identselt. Seevastu Fabricu determinism põhineb teisel küsimusel: "Kas piisavalt toetajaid nõustub selle koodi nende andmete alusel käitamise tulemusega?" Sellele vastamine on üsna lihtne loendamine ja mittedeterminismil pole ruumi sisse hiilida.

Kanga determinismil heakskiitmisel on mitmeid huvitavaid tagajärgi. Esiteks saab ahelkoodi kirjutada paljudes erinevates programmeerimiskeeltes, kuna neid ei pea determinismi jaoks kohandama (praegu toetatakse Go, Java ja JavaScript). Teiseks saab ahelkoodi mõne plokiahelas osaleja eest peita, kuna seda peavad täitma ainult kliendid ja kinnitajad (andmebaas ise on globaalselt nähtav). Lõpuks ja kõige olulisem on see, et Fabric kettkood saab teha asju, mis on teistes plokiahela keskkondades keelatud, näiteks kontrollida ilma veebipõhise veebi API abil. Halvimal juhul, kui iga kinnitaja saab sellelt API-lt erineva vastuse, ei saa klient ühegi konkreetse tulemuse jaoks piisavalt kinnitusi ja tehingut ei toimu. (Tuleb märkida, et Fabricu meeskonna liikmed ikka soovitama kasutades ahelkoodi sees deterministlikku loogikat, et vältida üllatusi.)

Millist hinda Fabric selle paindlikkuse eest maksab? Kui plokiahela eesmärk on eemaldada jagatud andmebaasipõhisest rakendusest vahendajad, siis Fabricu toetumine toetajatele astub sellest eesmärgist suure sammu eemale. Ahelas osalejate jaoks ei piisa enam ahelakoodi reeglite järgimisest – neil on vaja ka teatud teisi sõlme, et nad nõustuksid sellega. Veelgi hullem, pahatahtlik toetajate alamhulk võib heaks kiita andmebaasi muudatused, mis ei järgi üldse ahelkoodi. See annab toetajatele palju rohkem võimu kui tavaliste plokiahelate valideerijad, kes saavad tehinguid tsenseerida, kuid ei saa plokiahela reegleid rikkuda. Blockchaini rakenduste arendajad peavad otsustama, kas see kompromiss on nende konkreetsel juhul mõttekas.

Determinism	Kangas	MultiCin	Ethereum	Corda
MUDEL	Kinnitused	Kohandatud käitusaeg	Eesmärgiks ehitatud VM	Kohandatud käitusaeg
Keeled	Go + Java + JavaScript	JavaScript	Tahked	Java + Kotlin
Koodi nähtavus	Osapooled + toetajad	plokk Chain	plokk Chain	Osapooled + ülalpeetavad
Kohustatud	Ei	Jah	Jah	Ei (praegu)

Konfliktide ennetamine

Siiani oleme arutanud, kuidas erinevad plokiahela platvormid väljendavad tehingureegleid koodis ja kuidas nad deterministlikult tagavad, et iga sõlm rakendab neid reegleid identselt. Nüüd on aeg rääkida meie jõuproovi kolmandast aspektist: kuidas iga platvorm tegeleb võimalusega, et kaks iseenesest kehtivat tehingut lähevad üksteisega vastuollu? Kujutage kõige lihtsamas näites ette, et Alice'il on finantsreskontras 10 dollarit ja ta edastab kaks tehingut – üks saadab Bobile 8 dollarit ja teine ​​Charlie'le 7 dollarit. On selge, et ainult üks neist tehingutest võib olla edukas.

Kaks mudelit

Alustuseks võime MultiChaini ja Corda lähenemisviisi sellele probleemile rühmitada. Nagu varem kirjeldatud, kasutavad mõlemad tehingute ja nende reeglite esitamiseks sisend-väljund mudelit, milles iga tehingu sisend kulutab eelmise tehingu väljundi. See toob kaasa lihtsa põhimõtte konfliktide ennetamiseks: iga väljundit saab kulutada ainult üks kord. MultiChaini filtrid ja Corda lepingud võivad selle piirangu täielikuks jõustamiseks tugineda oma vastavatele platvormidele. Kuna Alice'i 10 dollarit esindab eelmine tehingu väljund, peatab see ühekordse kulu reegel automaatselt selle saatmise nii Bobile kui ka Charlie'le.

Vaatamata sellele sarnasusele on oluline välja tuua peamine erinevus selles, kuidas MultiChain ja Corda konflikte ennetavad. MultiChainis näeb iga sõlm iga tehingut ja saab seega iseseisvalt kontrollida, kas iga väljund kulutatakse ainult üks kord. Iga tehing, mis teeb eelnevalt kinnitatud tehingule topeltkulu, lükatakse koheselt ja automaatselt tagasi. Seevastu Cordas pole globaalset plokiahelat, seega on nende topeltkulutuste vältimiseks vaja notareid. Iga Corda väljundi olek määratakse notarile, kes peab allkirjastama kõik selle väljundi kulutamise tehingud, kinnitades, et seda pole varem kulutatud. Plokiahelas osalejad peavad usaldama notareid, et nad seda reeglit ausalt järgiksid, ja pahatahtlikud notarid võivad omal soovil kaost põhjustada. Nagu Fabricu kinnituste puhul, on ka see "ühekordne kulu teenusena” disainil on eelised konfidentsiaalsuse osas, kuid see toob uuesti kasutusele vahendajad, olles vastuolus plokiahela teraga. (Oluline on selgitada, et Corda notareid saavad juhtida osalejate rühmad, kasutades konsensusalgoritmi, nii et pearaamatu terviklikkust saab siiski kaitsta üksikute halbade osalejate eest).

Liigume edasi Ethereumi juurde. Meenutuseks kasutab Ethereum pigem lepinguid ja sõnumeid kui sisendeid ja väljundeid. Seetõttu pole tehingute konfliktid, nagu Alice'i kaks makset, plokiahela mootorile koheselt nähtavad. Selle asemel tuvastab ja blokeerib need leping mis töötleb tehinguid pärast nende tellimuse kinnitamist ketis. Alice'i iga makse töötlemisel kontrollitakse lepinguga, kas tema saldo on piisav. Kui Bobile 8 dollarit maksv tehing tuleb esimesena, töödeldakse seda tavapäraselt, jättes Alice'i kontole 2 dollarit. Selle tulemusena, kui leping töötleb teist Charlie'le 7 dollarit maksvat tehingut, näeb see, et Alice'il puuduvad vajalikud rahalised vahendid ja tehing katkeb.

Väljundid vs lepingud

Siiani oleme näinud kahte erinevat tehnikat konfliktsete tehingute vältimiseks – ühekordse kuluga väljundid MultiChainis ja Cordas ning lepingupõhine kinnitamine Ethereumis. Nii et kumb on parem?

Sellele küsimusele vastamiseks vaatleme näidet „1-of-2 multisignature” konto, millel on Gavini ja Heleni nimel 100 dollarit ja mis võimaldab neil mõlemal seda raha iseseisvalt kulutada. Gavin annab oma taotlusele korralduse maksta Donnale 80 dollarit ja mõne sekundi pärast tahab Helen Edwardile 40 dollarit saata. Kuna mõlema makse jaoks ei jätku rahalisi vahendeid, läheksid need tehingud paratamatult vastuollu. Kui mõlemad tehingud edastatakse, määrab tulemuse see, kumb jõuab ahelasse esimesena. Pange tähele, et erinevalt Alice'i näitest on see konflikt juhuslik, kuna keegi ei ürita rakenduse reegleid rikkuda – neil oli lihtsalt ebaõnne ajastus.

Arvestades selle konflikti esinemise tõenäosust, on põhiküsimus järgmine: kui kaua läheb Heleni sõlmel aega, et teada saada, et tema makse võib ebaõnnestuda, kui Gavin saadab oma tehingu välja? Mida lühem on see periood, seda tõenäolisem on, et Helen peatatakse seda makset tegemast, säästes teda ja tema avaldust hilisema üllatuse eest.

Sisend-väljund mudeli puhul on kõik tehingutevahelised konfliktid plokiahela platvormile otse nähtavad, kuna need kaks tehingut püüavad selgesõnaliselt kulutada sama eelmist väljundit. MultiChainis toimub see niipea, kui Gavini tehing on levinud Heleni sõlme, tavaliselt sekundi või vähema aja jooksul. Cordas keeldub väljundi notar Heleni tehingu allkirjastamise taotlusest, kuna see on juba Gavini oma allkirjastanud, nii et Helen saab kohe aru, et tema makse ebaõnnestub. (Kuigi kui Corda notar on ise levitatud, peab ta võib-olla mõne sekundi vastust ootama.) Mõlemal juhul pole vaja oodata tehingu kinnitamist ja tellimist plokiahelas.

Aga Ethereumi mudel? Sellisel juhul ei saa plokiahela platvorm koheselt teada, et konflikt tekib. Kuigi Heleni sõlm võib näha võrgus Gavini tehingut, ei saa ta teada, kuidas see Heleni enda tehingut mõjutab, kuna tema vaatenurgast on tegemist lihtsalt kahe samale lepingule saadetava sõnumiga. Võib-olla kümme sekundit hiljem, kui konfliktsete tehingute lõplik järjestus on plokiahelas kinnitatud, arvutab Heleni sõlm eeldatava tulemuse asemel tegeliku ja tema rakendus värskendab oma kuva vastavalt. Seniks jäävad nii Gavin kui Helen teadmatusse.

Kuid me ei tohiks sellest järeldada, et sisend-väljundmudel töötab alati kõige paremini. Mõelge meie näidisstsenaariumi variatsioonile, kus nii Gavin kui ka Helen taotlevad täpselt samal ajal väiksemaid 40-dollarise makseid algsest 100-dollarise saldo pealt. Sisend-väljund mudelis oleksid need tehingud vastuolus, kuna mõlemad kulutavad sama andmebaasi rida, mis sisaldab seda 100 dollarit, ja ainult üks maksetest õnnestub. Kuid Ethereumis töödeldakse mõlemat tehingut edukalt, olenemata nende lõplikust tellimusest, kuna kontol on mõlema jaoks piisavalt raha. Sel juhul täidab Ethereum ustavamalt Gavini ja Heleni kavatsusi.

Lugemis-kirjutamise komplektid

Lõpuks räägime Fabricust, mille kinnitusel põhinev lähenemine on nende kahe tehnika hübriid. Nagu varem selgitatud, kui Fabrici kliendisõlm soovib lepingule sõnumit saata, palub ta esmalt mõnel kinnitaval sõlmel see sõnum tema nimel täita. Kinnitavad sõlmed teevad seda sarnaselt Ethereumiga - lepingut nende kohaliku andmebaasi alusel -, kuid seda protsessi jälgitakse, mitte ei rakendata kohe. Iga kinnitaja salvestab loetavate ja kirjutatavate ridade komplekti, märkides ka nende ridade täpse versiooni sellel ajahetkel. Sellele versioonitud ridade lugemis-kirjutamiskomplektile viidatakse sõnaselgelt kinnituses ja see sisaldub tehingus, mida klient edastab.

Kangaste tehingute vahelised konfliktid lahendatakse, kui nende tellimus on ahelas lõplikult vormistatud. Iga sõlm töötleb iga tehingut iseseisvalt, kontrollides kinnituspoliitikat ja rakendades määratud andmebaasi muudatusi. Kui aga tehing loeb või kirjutab andmebaasirea versiooni, mida on eelmise tehinguga juba muudetud, siis seda teist tehingut ignoreeritakse. Et minna tagasi Alice'i vastuoluliste maksete juurde Bobile ja Charlie'le, loevad ja muudavad mõlemad tehingud sama rea ​​versiooni, mis sisaldab 10 dollarit, millega Alice alustas. Seega katkestatakse teine ​​tehing turvaliselt ja automaatselt.

Fabricu lähenemine konfliktide lahendamisele töötab suurepäraselt, kuid jõudluse ja paindlikkuse osas ühendab see kahest eelmisest mudelist halvima. Kuna kinnitused muudavad tehingud konkreetseteks lugemis-kirjutamiskomplektideks, põhjustaksid Gavini ja Heleni samaaegsed, kuid ühilduvad 40-dollarilised maksed konflikti, mida Ethereum väldib. Kuid Fabric ei saavuta sisend-väljundmudeli kiiruseeelist, kuna kinnitajad täidavad lepinguid plokiahela poolt kinnitatud andmebaasi uusima versiooni alusel, jättes tähelepanuta kinnitamata tehingud. Nii et kui Helen algatab oma makse mõni sekund pärast Gavinit, kuid enne, kui Gavini makse on plokiahelas kinnitatud, loob Fabric vastuolulisi tehinguid, mida puhas sisend-väljundmudel väldib.

Konfliktide ennetamine	Kangas	MultiCin	Ethereum	Corda
MUDEL	Lugemis-kirjutamise komplektid	Ühekordne kulu	Lepingu kontrollid	Ühekordne kulu
Kontrollimine	Sõltumatu	Sõltumatu	Sõltumatu	Usaldusväärsed notarid
Kiirus	~10s (kinnitus)	~1s (levi)	~10s (kinnitus)	0–5 s (notar)

Keeruline valik

Selles artiklis vaatlesime paljusid erinevaid viise, kuidas Corda, Ethereum, Fabric ja MultiChain lahendavad "nutikate lepingute" või plokiahelasse manustatud rakenduse koodi peamisi väljakutseid. Ja igal platvormil on erinevad vastused meie kolmele põhiküsimusele: kuidas on tehingureeglid esitatud? Kuidas koodi deterministlikult käivitatakse? Ja kuidas me konflikte ennetame?

Kes on siis meie nutika lepingu võitja? Praeguseks peaks olema selge, et lihtsat vastust pole. Iga platvorm kujutab endast keerulist mitmesuunalist kompromissi paindlikkuse, lihtsuse, jõudluse, vahendamise, ohutuse ja konfidentsiaalsuse vahel. Seega peab konkreetse rakenduse jaoks platvormi valimine algama selle rakenduse usaldusmudeli, sellega seotud tehingutüüpide ja nende tõenäoliste konfliktimustrite üksikasjalikust mõistmisest. Kui leiate, et keegi surub konkreetse nutika lepingu lahenduse peale enne, kui ta neile küsimustele vastuseid teab, soovitan viisakalt, kuid kindlalt nõuda, et nad võtaksid kasutusele "targema" lähenemisviisi.

Palun postitage kõik kommentaarid LinkedIn.