Pametni razplet pogodb: Hyperledger Fabric proti MultiChain proti Ethereum proti Cordi

Obstaja več kot en način, kako kodo postaviti na blockchain

V večini razprav o blockchainsu ni trajalo dolgo, da se je pojavil pojem "pametnih pogodb". V ljudski domišljiji pametne pogodbe avtomatizirajo izvajanje meddržavnih interakcij, ne da bi pri tem potrebovali zaupanja vrednega posrednika. Z izražanjem pravnih razmerij v kodi in ne v besedi obljubljajo, da bodo omogočile, da se transakcije odvijajo neposredno in brez napak, ne glede na to, ali so namerne ali ne.

S tehničnega vidika je pametna pogodba nekaj bolj specifičnega: računalniška koda, ki živi v verigi blokov in določa pravila za transakcije v tej verigi. Ta opis zveni dovolj preprosto, vendar se za njim skriva veliko razlik v tem, kako so ta pravila izražena, izvedena in potrjena. Pri izbiri platforme blockchain za novo aplikacijo se vprašanje »Ali ta platforma podpira pametne pogodbe?« ni pravi, da vprašam. Namesto tega se moramo vprašati: "Kakšno vrsto pametnih pogodb podpira ta platforma?"

V tem članku je moj cilj preučiti nekatere glavne razlike med pametnimi pogodbenimi pristopi in kompromisi, ki jih predstavljajo. To bom storil s pregledom štirih priljubljenih platform blockchain podjetij, ki podpirajo neko obliko prilagojene verižne kode. Najprej IBM-ove Tkanina Hyperledger, ki svoje pogodbe imenuje "verižna koda". Drugič, naša platforma MultiChain, ki predstavlja pametni filtri v različici 2.0. Tretjič, Ethereum (in dovoljeno Sklepčnost in burrow spin-offs), ki je populariziralo ime „pametna pogodba“. In končno, R3 Corda, ki v svojih transakcijah navaja „pogodbe“. Kljub vsej različni terminologiji se na koncu vsi nanašajo na isto stvar - kodo, specifično za aplikacijo, ki določa pravila verige.

Preden nadaljujem, bi moral opozoriti bralca, da je večina naslednjih vsebin tehnične narave in se seznani s splošnimi koncepti programiranja in baze podatkov. Za dobro ali slabo se temu ni mogoče izogniti - brez podrobnosti ni mogoče sprejeti ozaveščene odločitve o tem, ali naj uporabim blockchain za določen projekt in (če je tako) prava vrsta blockchaina, ki ga bomo uporabili.

Osnove blockchaina

Začnimo z nekim kontekstom. Predstavljajte si aplikacijo, ki si jo deli več organizacij in temelji na osnovni bazi podatkov. V tradicionalni centralizirani arhitekturi to bazo gosti in upravlja ena sama stranka, ki ji vsi udeleženci zaupajo, tudi če drug drugemu ne zaupajo. Transakcije, ki spreminjajo bazo podatkov, se začnejo samo s programi v sistemih te centralne stranke, pogosto kot odgovor na sporočila, ki jih prejmejo udeleženci. Baza podatkov preprosto naredi, kar ji rečejo, ker aplikaciji implicitno zaupajo, da ji pošiljajo samo transakcije, ki imajo smisel.

Blockchains zagotavljajo alternativni način upravljanja skupne baze podatkov brez zaupanja vrednega posrednika. V blockchainu vsak udeleženec vodi »vozlišče«, ki hrani kopijo baze podatkov in neodvisno obdeluje transakcije, ki jih spreminjajo. Udeleženci se identificirajo z uporabo javnih ključev ali "naslovov", od katerih ima vsak ustrezen zasebni ključ, ki je znan samo lastniku identitete. Medtem ko transakcije lahko ustvari katero koli vozlišče, jih "digitalno" podpiše zasebni ključ pobudnika, da dokaže njihov izvor.

Vozlišča se med seboj povežejo medsebojno, hitro širijo transakcije in "bloke", v katerih jih časovno zaznamuje in potrdi po omrežju. Sam blockchain je dobesedno veriga teh blokov, ki tvori urejen dnevnik vsake zgodovinske transakcije. Uporablja se „algoritem soglasja“, ki zagotavlja, da se vsa vozlišča strinjajo glede vsebine blokovne verige, ne da bi pri tem potrebovali centraliziran nadzor. (Upoštevajte, da del tega opisa ne velja za Corda, v kateri ima vsako vozlišče le delno kopijo baze podatkov in ni globalne verige blokov. O tem bomo več govorili.)

Načeloma je katero koli aplikacijo v skupni rabi podatkov mogoče arhitekturirati z uporabo blockchaina v njenem jedru. Vendar to ustvarja številne tehnične izzive, ki ne obstajajo v centraliziranem scenariju:

• Pravila o transakcijah. Če lahko kateri koli udeleženec neposredno spremeni bazo podatkov, kako zagotovimo, da upoštevajo pravila aplikacije? Kaj prepreči enemu uporabniku, da vsebino baze podatkov pokvari na samovšečen način?
• Odločnost. Ko bodo ta pravila definirana, jih bodo večkrat uporabila več vozlišč pri obdelavi transakcij za lastno kopijo baze podatkov. Kako zagotovimo, da vsako vozlišče doseže popolnoma enak rezultat?
• Preprečevanje konfliktov. Kako ravnamo z dvema transakcijama, ki vsaka sledita pravilom aplikacije, vendar sta kljub temu v nasprotju? Konflikti lahko izvirajo iz namernega poskusa igre in so nedolžni rezultat slabe sreče in časovne omejitve.

Kje torej prihajajo pametne pogodbe, pametni filtri in verižna koda? Njihov osnovni namen je sodelovanje z osnovno infrastrukturo blockchaina, da bi rešili te izzive. Pametne pogodbe so decentralizirani ekvivalent kode aplikacije - namesto da bi se izvajali na enem osrednjem mestu, se izvajajo na več vozliščih v verigi blokov in ustvarjajo ali potrdijo transakcije, ki spreminjajo vsebino baze podatkov.

Začnimo s pravili o transakcijah, ki so prvi od teh izzivov, in poglejmo, kako se izražajo v Fabric, MultiChain, Ethereum in Corda.

Pravila o transakcijah

Pravila o transakcijah opravljajo določeno funkcijo v podatkovnih bazah, ki jih poganja blockchain - omejujejo transformacije ki se lahko izvede v stanju te baze podatkov. To je potrebno, ker lahko transakcije blockchaina začne kateri koli od njegovih udeležencev in ti udeleženci ne zaupajo drug drugemu v zadostni meri, da bi jim lahko poljubno spreminjali bazo podatkov.

Poglejmo dva primera, zakaj so potrebna pravila transakcij. Najprej si predstavljajte blockchain, namenjen združevanju in časovnem žigosanju dokumentov PDF, ki jih objavijo njegovi udeleženci. V tem primeru nihče ne bi smel imeti pravice do odstranjevanja ali spreminjanja dokumentov, saj bi to spodkopalo celoten namen sistema - obstojnost dokumentov. Drugič, razmislite o blockchainu, ki predstavlja skupno finančno knjigo, ki spremlja stanja svojih uporabnikov. Udeležencu ne moremo dovoliti, da poljubno napihne svoj saldo ali odvzame denar drugim.

Vhodi in izhodi

Naše platforme blockchain temeljijo na dveh širokih pristopih za izražanje pravil o transakcijah. Prvi, ki mu pravim "vhodno-izhodni model", se uporablja v MultiChainu in Cordi. Tu transakcije izrecno navajajo vrstico baze podatkov ali države, ki jih izbrišejo in ustvarijo, tako da tvorijo niz "vhodov" in "izhodov". Spreminjanje vrstice je izraženo kot enakovredna operacija brisanja te vrstice in ustvarjanja nove na njenem mestu.

Ker so vrstice zbirke podatkov izbrisane samo v vhodih in ustvarjene samo v izhodih, mora vsak vhod "porabiti" rezultate prejšnje transakcije. Trenutno stanje baze podatkov je opredeljeno kot niz "neizkoriščenih transakcijskih izhodov" ali "UTXOs", tj. Izhodov iz prejšnjih transakcij, ki še niso bili uporabljeni. Transakcije lahko vsebujejo tudi dodatne informacije, imenovane "metapodatki", "ukazi" ali "priloge", ki ne postanejo del baze podatkov, ampak pomagajo določiti njihov pomen ali namen.

Glede na te tri sklope vhodov, izhodov in metapodatkov je veljavnost transakcije v MultiChainu ali Cordi določena z neko kodo, ki lahko na teh nizih izvede poljubne izračune. Ta koda lahko potrdi transakcijo ali pa vrne napako z ustrezno razlago. Vhodno-izhodni model si lahko predstavljate kot avtomatiziranega „inšpektorja“, ki ima kontrolni seznam, ki zagotavlja, da transakcije sledijo vsakemu pravilu. Če transakcija ne uspe katerega koli od teh preverjanj, jo bodo samodejno zavrnila vsa vozlišča v omrežju.

Treba je opozoriti, da ga MultiChain in Corda, kljub deljenju vhodno-izhodnega modela, izvajata zelo različno. V MultiChainu lahko izhodi vsebujejo sredstva in / ali podatke v JSON, besedilni ali binarni obliki. Pravila so opredeljena v „filtrih transakcij“ ali „filtrih toka“, ki jih je mogoče nastaviti za preverjanje vseh transakcij ali samo tistih, ki vključujejo določena sredstva ali skupine podatkov. V nasprotju s tem je stanje izhoda Corde predstavljeno s predmetom v programskem jeziku Java ali Kotlin z definiranimi podatkovnimi polji. Pravila družbe Corda so opredeljena v „pogodbah“, ki so priložene posebnim državam, pogodba države pa se uporablja samo za transakcije, ki to stanje vsebujejo v svojih vhodih ali izhodih. To se nanaša na Corda nenavaden model vidnosti, pri katerih lahko transakcije vidijo samo nasprotne stranke ali tisti, na katere poznejše transakcije vplivajo.

Pogodbe in sporočila

Drugi pristop, ki mu pravim "model pogodbe in sporočila", je uporabljen v Hyperledger Fabric in Ethereum. Tu lahko na blokovni verigi ustvarite več "pametnih pogodb" ali "verižnih kod", in vsaka ima svojo bazo podatkov in pripadajočo kodo. Pogodbeno bazo podatkov lahko spreminja le koda, ne pa neposredno s transakcijami v blokovni verigi. Ta vzorec oblikovanja je podoben "kapsuliranju" kode in podatkov v objektno usmerjenem programiranju.

Pri tem modelu se transakcija blockchain začne kot sporočilo, poslano pogodbi, z nekaj neobveznimi parametri ali podatki. Koda pogodbe je izvedena kot odziv na sporočilo in parametre, v okviru te reakcije pa je mogoče brati in pisati svojo bazo podatkov. Pogodbe lahko pošiljajo sporočila tudi drugim pogodbam, vendar ne morejo neposredno dostopati do svojih baz podatkov. Pogodbe v jeziku relacijskih baz podatkov delujejo kot prisiljeni "Shranjeni postopki", kjer gre za ves dostop do baze podatkov prek neke vnaprej določene kode.

Tako Fabric kot Quorum, različica Ethereuma, zapletata to sliko, saj omrežju omogočata določitev več "kanalov" ali "zasebnih stanj". Cilj je ublažiti problem zaupnosti blockchain z ustvarjanjem ločenih okolij, od katerih je vsako vidno le določeni podskupini udeležencev. Čeprav se to v teoriji sliši obetavno, so v resnici pogodbe in podatki v vsakem kanalu ali zasebni državi ločeni od tistih v drugih. Posledično so ta okolja v smislu pametnih pogodb enakovredna ločenim blockchainom.

Primer pravila

Poglejmo, kako izvajati pravila transakcij za finančno knjigo z enim premoženjem s tema dvema modeloma. Vsaka vrstica v podatkovni bazi naše knjige ima dva stolpca, ki vsebujeta naslov lastnika in količino sredstva v lasti. V modelu input-output morajo transakcije izpolnjevati dva pogoja:

1. Skupna količina sredstev v izidih transakcije se mora ujemati s skupnimi vložki. S tem uporabniki preprečujejo samovoljno ustvarjanje ali brisanje denarja.
2. Vsako transakcijo mora podpisati lastnik vsakega svojega vložka. To uporabnikom preprečuje, da bi brez dovoljenja drug drugemu porabili denar.

Ta dva pogoja sta skupaj potrebna za oblikovanje preprostega, a sposobnega za preživetje finančnega sistema.

V modelu pogodba-sporočilo pogodba sredstva podpira sporočilo »pošlji plačilo«, ki ima tri parametre: naslov pošiljatelja, naslov prejemnika in količino, ki jo je treba poslati. Kot odgovor pogodba izvede naslednje štiri korake:

1. Preverite, ali je transakcijo podpisal pošiljatelj.
2. Preverite, ali ima pošiljatelj dovolj sredstev.
3. Zaprite zahtevano količino iz vrstice pošiljatelja.
4. To količino dodajte v vrstico prejemnika.

Če kateri od pregledov v prvih dveh korakih ne bo uspel, bo pogodba prekinjena in plačilo ne bo izvedeno.

Tako sta vhodno-izhodna in pogodbeno-sporočilna modela učinkovita načina za določitev transakcijskih pravil in varovanje skupne baze podatkov. Na teoretični ravni je mogoče vsak od teh modelov uporabiti za simulacijo drugega. V praksi pa bo najprimernejši model odvisen od izdelave aplikacije. Ali vsaka transakcija vpliva na nekaj ali več informacij? Ali moramo biti sposobni zagotoviti neodvisnost transakcij? Ali ima vsak podatek jasnega lastnika ali je treba deliti neko globalno stanje?

Tukaj je zunaj našega področja raziskovanja, kako naj bi odgovori vplivali na izbiro med tema dvema modeloma. Toda kot splošno vodilo je pri razvoju nove aplikacije blockchain vredno poskusiti izraziti svoja pravila o transakcijah v obeh oblikah in videti, katera ustreza bolj naravno. Razlika se bo izrazila v: (a) enostavnosti programiranja, (b) zahtevah po shranjevanju in pretoku ter (c) hitrosti odkrivanja konfliktov. O tej zadnji številki bomo govorili kasneje.

Vgrajena pravila

Kar zadeva pravila transakcij, obstaja en način, kako se MultiChain posebej razlikuje od Fabric, Ethereum in Corda. Za razliko od teh drugih platform ima MultiChain več vgrajenih abstrakcij, ki zagotavljajo nekaj osnovnih gradnikov za aplikacije, ki jih poganja blockchain, brez zahtevajo razvijalci, da napišejo svojo kodo. Te abstrakcije zajemajo tri področja, ki so običajno potrebna: (a) dinamična dovoljenja, (b) prenosljiva sredstva in (c) shranjevanje podatkov.

Na primer, MultiChain upravlja dovoljenja za povezovanje v omrežje, pošiljanje in prejemanje transakcij, ustvarjanje sredstev ali pretokov ali nadzor nad dovoljenji drugih uporabnikov. Varno in atomsko je mogoče izdati, prenašati, upokojevati ali zamenjati več gnljivih sredstev. V verigi je mogoče ustvariti poljubno število "tokov" za objavljanje, indeksiranje in pridobivanje podatkov o verigi ali zunaj verige v JSON, besedilnem ali binarnem formatu. Vsa pravila o transakcijah za te abstrakcije so na voljo zunaj okvira.

Pri razvoju aplikacije na MultiChainu je to vgrajeno funkcionalnost mogoče prezreti in izraziti pravila o transakcijah samo s pametnimi filtri. Vendar so pametni filtri zasnovani tako, da delujejo skupaj z vgrajenimi abstrakcijami, tako da omogočajo njihovo privzeto vedenje omejeno na prilagojene načine. Na primer, dovoljenje za nekatere dejavnosti lahko nadzirajo določeni skrbniki in ne privzeto vedenje, kjer to počne kateri koli administrator. Prenos določenih sredstev je lahko časovno omejen ali pa je potrebna dodatna odobritev nad določenim zneskom. Podatke v določenem toku je mogoče potrditi, da se zagotovi, da so sestavljeni samo iz struktur JSON z zahtevanimi polji in vrednostmi.

V vseh teh primerih pametni filtri ustvarjajo dodatne zahteve za potrditev transakcij, vendar ne odstrani enostavna pravila, ki so vgrajena. To lahko pomaga rešiti enega ključnih izzivov v blockchain aplikacijah: dejstvo, da lahko hrošč v neki verižni kodi privede do katastrofalnih posledic. Nešteto primerov te težave smo videli v javnem bloku Ethereum, najbolj znanem v Smrt DAO in Paritetne večnamenske napake. Širše raziskave v pametnih pogodbah Ethereum so našli veliko skupnih ranljivosti, ki napadalcem omogočajo krajo ali zamrznitev sredstev drugih ljudi.

Seveda lahko pametni filtri MultiChain vsebujejo tudi hrošče, vendar so njihove posledice po obsegu bolj omejene. Na primer, pravila o vgrajenih sredstvih enemu uporabniku preprečujejo, da bi porabil drug denar ali slučajno izginila svoj denar, ne glede na to, kakšna druga logika vsebuje pametni filter. Če se v pametnem filtru najde napaka, jo je mogoče izključiti in zamenjati s popravljeno različico, osnovna celovitost knjige pa je zaščitena. Filozofsko gledano je MultiChain bližje tradicionalnim arhitekturam baz podatkov, kjer platforma baze podatkov ponuja številne vgrajene abstrakcije, kot so stolpci, tabele, indeksi in omejitve. Zmogljivejše funkcije, kot so sprožilci in shranjeni postopki, lahko razvijalci aplikacij kodirajo, če so dejansko potrebni.

Pravila o transakcijah	Fabric	MultiChain	Ethereum	Corda
Model	Pogodba – sporočilo	Vhod-izhod	Pogodba – sporočilo	Vhod-izhod
Vgrajene	Noben	Dovoljenja + sredstva + tokovi	Noben	Noben

Odločnost

Pojdimo na naslednji del našega razstavljanja. Ne glede na to, kateri pristop izberemo, so pravila transakcij po meri aplikacije blockchain izražena kot računalniška koda, ki jo napišejo razvijalci aplikacij. Za razliko od centraliziranih aplikacij se bo ta koda izvajala večkrat in na več mestih za vsako transakcijo. To je zato, ker mora več vozlišč blockchain, ki pripadajo različnim udeležencem, vsak preveriti in / ali izvesti to transakcijo zase.

To ponavljajoče in odvečno izvrševanje kode uvaja novo zahtevo, ki jo v centraliziranih aplikacijah le redko najdemo: determinizem. V okviru računanja determinizem pomeni, da bo kos kode vedno dal enak odgovor za iste parametre, ne glede na to, kje in kdaj se izvaja. To je nujno pri kodi, ki deluje z blokovno verigo, saj se brez odločnosti lahko soglasje med vozlišči v tej verigi katastrofalno poruši.

Poglejmo, kako je to videti v praksi, najprej v modelu vhod-izhod. Če imata dve vozlišči različno mnenje o veljavnosti transakcije, bo eno sprejelo blok, ki vsebuje to transakcijo, drugo pa ne. Ker se vsak blok izrecno poveže nazaj na prejšnji blok, bo to ustvarilo stalni "vilice" v omrežju, pri čemer eno ali več vozlišč od tega trenutka ne bo sprejelo večinskega mnenja o celotni vsebini blockchaina. Vozlišča v manjšini bodo odrezana iz razvijajočega se stanja podatkovne baze in aplikacije ne bodo mogli več učinkovito uporabljati.

Zdaj pa poglejmo, kaj se zgodi, če se v modelu pogodba-sporočilo poruši soglasje. Če imata dve vozlišči različno mnenje o tem, kako mora pogodba odgovoriti na določeno sporočilo, lahko to povzroči razliko v vsebini njihovih baz. To pa lahko vpliva na odziv pogodbe na prihodnja sporočila, vključno s sporočili, ki jih pošilja drugim pogodbam. Končni rezultat je vse večja razhajanja med različnimi vozlišči o stanju baze podatkov. (Polje »stanje korenine« v blokih Ethereum zagotavlja, da kakršna koli razlika v odzivih pogodb takoj pripelje do popolnoma katastrofalne vilice blockchain, namesto da bi tvegali, da se nekaj časa skrivate.)

Viri nedefinizma

Torej je nedefinizem v blockchain kodi očitno problem. Če pa so osnovni gradniki računanja, na primer aritmetika, deterministični, kaj moramo skrbeti? No, izkaže se, kar nekaj stvari:

• Najbolj očitno so generatorji naključnih števil, saj so po definiciji zasnovani tako, da vsakič ustvarijo drugačen rezultat.
• Preverjanje trenutnega časa, saj vozlišča ne bodo obdelovala transakcij ob istem času in v vsakem primeru njihove ure morda ne bodo sinhronizirane. (Še vedno je mogoče uveljaviti pravila, ki so odvisna od časa, tako da se sklicujete na časovne žige znotraj same blockchain.)
• Poizvedovanje o zunanjih virih, kot so internet, diskovne datoteke ali drugi programi, ki se izvajajo v računalniku. Za te vire ni mogoče zagotoviti enakega odziva in lahko postanejo nedosegljivi.
• Izvajanje več kosov kode vzporedno z "nitmi", ker to vodi v "stanje dirke", kjer vrstnega reda, v katerem se ti procesi zaključijo, ni mogoče predvideti.
• Izvajanje kakršnih koli izračunov s plavajočo vejico, ki lahko dajo celo minimalno različne odgovore na različne arhitekture računalniških procesorjev.

Naše štiri blockchain platforme uporabljajo več različnih pristopov, da se izognemo tem pastem.

Odločna izvedba

Začnimo z Ethereumom, saj je njegov pristop najbolj "čist". Pogodbe Ethereum so izražene v posebni obliki, imenovani "Ethereum bytecode", ki jo izvaja Virtualni stroj Ethereum ("EVM"). Programerji ne pišejo bajt-kode neposredno, temveč ga generirajo ali "kompilirajo" iz programskega jezika, podobnega JavaScriptu, imenovanega Solidity. (Drugi jeziki so bili na voljo, vendar so bili od takrat zastareli.) Določitev zagotavljata dejstva, da bajt kodi Solidity in Ethereum ne moreta kodirati nobenih nedeterminističnih operacij - to je tako preprosto.

MultiChain filtri in Corda pogodbe izberejo drugačen pristop s prilagoditvijo obstoječih programskih jezikov in izvajalskih okolij. MultiChain uporablja JavaScript, ki se izvaja v Googlovih V8 motor, ki tvori tudi jedro brskalnika Chrome in platforme Node.js, vendar z viri nedefinizma ni. Podobno Corda uporablja Java oz Kotlin, ki sta oba sestavljena v „Java bytecode“, ki se izvrši znotraj Java Virtual Machine („JVM“). Za zdaj Corda uporablja Oracle-ov standardni nedeterministični JVM, vendar še vedno poteka delo za integracijo a deterministična različica. V tem času morajo razvijalci pogodb za Cordo paziti, da v svoji kodi ne dovolijo nedefinicizma.

Kako se Ethereumov purizem primerja z evolucijskim pristopom MultiChain in Corda? Glavna prednost Ethereuma je minimiziranje tveganj - manjša verjetnost je, da bo vgrajeni virtualni stroj vseboval nenamerni vir nedefinizma. Čeprav bi takšen nadzor lahko popravil posodobitev programske opreme, bi bil to moteč za vsako verigo, ki ni bila dovolj srečna, da bi naletela nanjo. Težava Ethereuma pa je, da Solidity in EVM tvorita majhen in nastajajoč ekosistem v širšem kontekstu programskih jezikov in okolja za izvajanje. Za primerjavo, JavaScript in Java sta zgornja dva jezika na Githubu, delujejo na milijardah digitalnih naprav in imajo čas delovanja, ki je bil desetletja optimiziran. Verjetno zato javni blok Ethereum razmišlja o prehodu na eWASM, deterministična vilica nastajajočega standarda WebAssembly.

Določenost s potrditvijo

Ko gre za determinizem, Hyperledger Fabric sprejme povsem drugačen pristop. V Fabric, ko vozlišče »odjemalec« želi poslati sporočilo na neko verižno kodo, to sporočilo najprej pošlje nekaterim voznikom »potrjevalca«. Vsako od teh vozlišč izvede verižno kodo neodvisno in oblikuje mnenje o sporočilu učinek v zbirki podatkov te verižne kode. Ta mnenja se pošljejo stranki skupaj z digitalnim podpisom, ki predstavlja formalno "potrditev". Če stranka prejme dovolj priporočil predvidenega rezultata, ustvari transakcijo, ki vsebuje ta priporočila, in jo odda za vključitev v verigo.

Da bi zagotovili determinizem, ima vsak kos verižne kode "politiko odobritve", ki natančno določa, kakšna stopnja odobritve je potrebna, da postanejo njene transakcije veljavne. Na primer, v pravilniku ene verižne kode lahko piše, da se priporočila zahtevajo od vsaj polovice vozlišč blokovne verige. Drug lahko zahteva potrditev katere koli od treh zaupanja vrednih strank. Kakor koli že, vsako vozlišče lahko samostojno preveri, ali so bila prejeta potrebna priporočila.

Da bi razjasnili razliko, determinizem v večini blokchain platform temelji na vprašanju: "Kakšen je rezultat te kode na teh podatkih?" - in biti moramo popolnoma prepričani, da bo vsako vozlišče na to vprašanje odgovorilo enako. Nasprotno pa determinizem v Fabric temelji na drugačnem vprašanju: "Ali se dovolj potrjencev strinja glede rezultata uporabe te kode na teh podatkih?" Odgovor na to je precej preprosto vprašanje štetja in ni prostora, da bi se prikradel nedefinističnost.

Fabricijev determinizem s potrditvijo ima številne zanimive posledice. Prvič, verižno kodo lahko zapišemo v več različnih programskih jezikih, saj jih ni treba prilagoditi determinizmu (Go, Java in JavaScript so trenutno podprti). Drugič, verižno kodo je mogoče skriti pred nekaterimi udeleženci blockchaina, saj jo morajo izvajati samo stranke in pooblaščeni uporabniki (sama baza podatkov je globalno vidna). Končno in predvsem pa verižna koda Fabric lahko počne stvari, ki so prepovedane v drugih okoljih verige blokov, na primer preverjanje vremena z uporabo spletnega spletnega API-ja. V najslabšem primeru, če vsak pooblaščenec dobi drugačen odgovor od tega API-ja, odjemalec ne bo dobil dovolj potrditev za določen izid in nobena transakcija ne bo izvedena. (Treba je opozoriti, da člani ekipe Fabric še vedno Priporočamo z uporabo deterministične logike znotraj verižne kode, da se izognemo presenečenjem.)

Kakšno ceno plača Fabric za to prilagodljivost? Če je namen verige blokov odstraniti posrednike iz aplikacije, ki jo poganja baza podatkov, je zanašanje podjetja Fabric na podpornike velik korak stran od tega cilja. Za udeležence v verigi ni več dovolj, da upoštevajo pravila verižne kode - potrebujejo tudi nekatera druga vozlišča, da se strinjajo, da so to storili. Še huje pa je, da lahko zlonamerna podmnožica odobriteljev odobri spremembe zbirke podatkov, ki sploh ne sledijo verižni kodi. To daje indontantom veliko več moči kot validatorji v običajnih verigah blokov, ki lahko cenzurirajo transakcije, vendar ne morejo kršiti pravil verige blokov. Razvijalci aplikacij Blockchain se morajo odločiti, ali je ta kompromis smiseln v njihovem konkretnem primeru.

Odločnost	Fabric	MultiChain	Ethereum	Corda
Model	Zaveze	Prilagojeno izvajanje	Namensko zgrajena VM	Prilagojeno izvajanje
jeziki	Pojdi + Java + JavaScript	JavaScript	Očistost	Java + Kotlin
Vidnost kode	Nasprotne stranke + pooblaščence	Blockchain	Blockchain	Nasprotne stranke + odvisnih oseb
Prisilno	Ne	Da	Da	Ne (za zdaj)

Preprečevanje konfliktov

Do sedaj smo razpravljali o tem, kako različne platforme blockchain izražajo transakcijska pravila v kodi in kako determinirano zagotavljajo, da vsako vozlišče ta pravila uporablja enako. Zdaj je čas, da spregovorimo o tretjem vidiku našega razstavljanja: kako se vsaka platforma spopada z možnostjo, da se dve transakciji, ki veljata sama po sebi, medsebojno spopadata? V najenostavnejšem primeru si predstavljajte, da ima Alice 10 dolarjev v finančni knjigi in oddaja dve transakciji - ena bo Bobu poslala 8 USD, Charlieju pa 7 USD. Jasno je, da lahko samo ena od teh transakcij uspe.

Dva modela

Začnemo lahko tako, da pristop MultiChain in Corda k tej težavi združimo skupaj. Kot je bilo opisano prej, oba uporabljata vhodno-izhodni model za predstavitev transakcij in njihovih pravil, v katerem vsak transakcijski vložek porabi predhodni transakcijski izhod. To vodi do preprostega načela za preprečevanje konfliktov: vsak rezultat je mogoče porabiti samo enkrat. MultiChain filtri in Corda pogodbe lahko za popolno uveljavljanje te omejitve zanesejo na svoje platforme. Ker Aliceinih 10 dolarjev predstavlja predhodni izhod transakcije, to pravilo enkratne porabe samodejno ustavi, da jih pošlje tako Bobu kot Charlieju.

Kljub tej podobnosti je pomembno opozoriti na ključno razliko v načinu, kako MultiChain in Corda preprečujeta konflikte. V MultiChain vsako vozlišče vidi vsako transakcijo in tako lahko samostojno preveri, ali je vsak izhod porabljen samo enkrat. Vsaka transakcija, ki izvede dvojno porabo v primerjavi s predhodno potrjeno transakcijo, bo takoj in samodejno zavrnjena. Nasprotno pa v Cordi ne obstaja globalni blockchain, zato so za to, da bi preprečili te dvojne porabe, potrebni "notarji". Vsako izhodno stanje Corde je dodeljeno notarju, ki mora podpisati kakršno koli transakcijsko porabo, ki izhaja, in potrditi, da ni bila porabljena prej. Udeleženci blockchaina morajo notarjem zaupati, da bodo to pravilo pošteno upoštevali, zlonamerni notarji pa lahko po svoji volji povzročijo opustošenje. Kot pri priporočilih v Fabric, tudi taenkratno porabo kot storitev"Oblika ima prednosti glede zaupnosti, vendar ponovno uvaja posrednike, ki nasprotujejo zrnu blockchain. (Pomembno je pojasniti, da lahko z notarji Corda vodijo skupine udeležencev z uporabo soglasnega algoritma, zato je integriteto knjige še vedno mogoče zaščititi pred posameznimi slabimi akterji).

Pojdimo na Ethereum. Spomnimo, Ethereum uporablja pogodbe in sporočila in ne vhode in izhode. Kot rezultat, transakcijski konflikti, kot sta Aliceva dva plačila, niso takoj vidni motorju blockchaina. Namesto tega jih zazna in blokira Naročilo ki obdela transakcije po potrditvi njihovega naročila na verigi. Ob obdelavi vsakega od Aliceinih plačil pogodba preveri, ali je njeno stanje zadostno. Če bo transakcija, ki bo Bob plačala 8 USD, najprej obdelana, bo obdelana kot običajno, Alice pa bo imela 2 USD na računu. Ko pogodba obdela drugo transakcijo, ko je Charlieju plačal 7 dolarjev, posledično ugotovi, da Alice nima potrebnih sredstev in transakcija prekine.

Končni rezultati v primerjavi s pogodbami

Doslej smo videli dve različni tehniki za preprečevanje konfliktnih transakcij - izhode z enkratno porabo v MultiChainu in Cordi ter preverjanje na podlagi pogodbe v Ethereumu. Torej, kaj je boljše?

Da bi lažje odgovorili na to vprašanje, si oglejmo primer računa »1-of-2 multisignature«, ki ima v imenu Gavina in Helene 100 USD in omogoča obema, da ta denar porabita samostojno. Gavin naroči svoji prijavi, naj Donni plača 80 dolarjev, nekaj sekund pozneje pa želi Helen poslati 40 dolarjev Edwardu. Ker ni dovolj sredstev za obe plačili, bi bile te transakcije neizogibno v nasprotju. V primeru, da se obe transakciji oddajata, bo izid določen s tistim, ki se najprej poda v verigo. Upoštevajte, da je v nasprotju z Alicein primer naključno, ker nihče ne poskuša prekršiti pravil aplikacije - preprosto je imel nesrečen čas.

Glede na verjetnost, da se bo ta konflikt zgodil, je ključno vprašanje: Ko Gavin pošlje svojo transakcijo, koliko časa bo Helenino vozlišče vedelo, da njeno plačilo morda ne bo uspelo? Čim krajše je to obdobje, tem bolj verjetno je, da bo Helen preprečila poskus tega plačila in tako rešila njo in njeno prošnjo pred poznejšim presenečenjem.

Pri vhodno-izhodnem modelu je vsak konflikt med transakcijami neposredno viden na platformi blockchain, saj bosta ti dve transakciji izrecno poskušali porabiti isti prejšnji izhod. V MultiChainu se to zgodi takoj, ko se Gavinova transakcija razširi na Helenovo vozlišče, običajno v sekundi ali manj. V Cordi bo notar izhoda zavrnil prošnjo za podpis Helenine transakcije, saj je že podpisal Gavinovo, zato bo Helen takoj vedela, da njeno plačilo ne bo uspelo. (Čeprav je notar Corde razdeljen sam, bo morda morala počakati nekaj sekund za odgovor.) Kakorkoli že, ni treba čakati, da se transakcija potrdi in naroči v blockchainu.

Kaj pa Ethereumov model? V tem primeru platforma blockchain ne more takoj vedeti, da bo prišlo do konflikta. Helenino vozlišče lahko vidi Gavinovo transakcijo v omrežju, vendar ne more vedeti, kako bo to vplivalo na Helenino lastno transakcijo, saj gre z njegove perspektive za dve pogodbi, ki ju pošljeta le dve sporočili. Morda deset sekund pozneje, ko bo na verigi blokov potrjeno končno naročilo nasprotujočih si transakcij, bo Helenino vozlišče preračunalo dejanski namesto pričakovanega rezultata in njena aplikacija bo ustrezno posodobila svoj prikaz. Medtem bosta tako Gavin kot Helena ostala v temi.

Iz tega pa ne smemo sklepati, da vhodno-izhodni model vedno deluje najbolje. Razmislite o različici v našem primernem scenariju, kjer tako Gavin kot Helen zahtevata manjše plačilo v višini 40 dolarjev iz prvotnega salda v višini 100 dolarjev istočasno. V vhodno-izhodnem modelu bi bile te transakcije v nasprotju, saj oba porabita isto vrstico baze podatkov, ki vsebuje 100 USD, in bi uspelo le eno od plačil. Toda v Ethereumu bi bili obe transakciji uspešno obdelani, ne glede na njihovo končno naročilo, saj račun vsebuje zadostna sredstva za obe. V tem primeru Ethereum bolj zvesto izpolnjuje Gavinove in Helenine namene.

Kompleti za branje in pisanje

Na koncu se pogovorimo o Fabric, katerega pristop, ki temelji na odobritvi, je hibrid teh dveh tehnik. Kot je bilo že pojasnjeno, ko vozlišče Fabric "odjemalec" želi poslati sporočilo pogodbi, najprej prosi nekaj potrditvenih vozlišč, da to sporočilo izvršijo v njegovem imenu. Vozlišča za odobritev to počnejo na podoben način kot Ethereum - izvajajo pogodbo proti njihovi lokalni bazi podatkov - vendar je ta postopek opazen in ne takoj uporabljen. Vsak indosant beleži niz vrstic, ki bi jih bilo mogoče prebrati in zapisati, pri čemer upošteva tudi natančno različico teh vrstic v tistem trenutku. Ta "bralno-pisalni nabor" različic z različicami je izrecno naveden v priporočilu in vključen v transakcijo, ki jo odjemalec predvaja.

Konflikti med transakcijami Fabric se rešijo, ko je njihovo naročilo dokončano v verigi. Vsako vozlišče vsako transakcijo obdela neodvisno, preveri pravilnike o odobritvi in ​​uporabi določene spremembe baze podatkov. Če pa transakcija bere ali napiše različico vrstice v bazo podatkov, ki je bila že spremenjena s prejšnjo transakcijo, potem se ta druga transakcija ne upošteva. Če se vrnemo k nasprotujočim si plačilom Alice Bobu in Charlieju, bosta obe transakciji prebrali in spremenili isto različico vrstice, ki vsebuje 10 USD, s katerimi je začela Alice. Torej bo druga transakcija varno in samodejno prekinjena.

Fabrikov pristop k reševanju konfliktov deluje povsem v redu, vendar glede na učinkovitost in prilagodljivost združuje najslabši od prejšnjih dveh modelov. Ker pooblastila pretvarjajo transakcije v določene sklope za branje in pisanje, bi hkratna, a združljiva plačila Gavina in Helene v višini 40 USD privedla do konflikta, ki se mu Ethereum izogne. Vendar Fabric ne pridobi prednosti glede hitrosti vhodno-izhodnega modela, saj indosanti izvršijo pogodbe z najnovejšo različico zbirke podatkov, ki jo potrdi veriga blokov, in ignorirajo nepotrjene transakcije. Torej, če Helen začne plačilo nekaj sekund po Gavinu, vendar preden je Gavinovo potrjeno na verigi blokov, bo Fabric ustvaril nasprotujoče si transakcije, ki se jim izogne ​​čisti vhodno-izhodni model.

Preprečevanje konfliktov	Fabric	MultiChain	Ethereum	Corda
Model	Kompleti za branje in pisanje	Enkratna poraba	Preverjanje pogodb	Enkratna poraba
Preverjanje	Neodvisni	Neodvisni	Neodvisni	Zaupanja vredni notarji
Hitrost	~ 10 s (potrditev)	~ 1s (razmnoževanje)	~ 10 s (potrditev)	0 ~ 5s (notar)

Kompleksna izbira

V tem delu smo pregledali številne različne načine, na katere Corda, Ethereum, Fabric in MultiChain obravnavajo ključne izzive "pametnih pogodb" ali aplikacijske kode, ki je vdelana v blockchain. In vsaka platforma ima različne odgovore na naša tri temeljna vprašanja: Kako so predstavljena pravila transakcij? Kako se koda izvaja deterministično? In kako preprečimo konflikte?

Kdo je torej zmagovalec našega pametnega razpisa? Zdaj bi moralo biti očitno, da preprostega odgovora ni. Vsaka platforma predstavlja zapleten večstranski kompromis med fleksibilnostjo, preprostostjo, zmogljivostjo, disintermediacijo, varnostjo in zaupnostjo. Izbira platforme za določeno aplikacijo se mora torej začeti s podrobnim razumevanjem zaupanja vrednega modela te aplikacije, vrste transakcij, ki jih vključuje, in njihovih verjetnih vzorcev konfliktov. Če najdete nekoga, ki potiska določeno rešitev pametne pogodbe, preden pozna odgovore na ta vprašanja, predlagam, da vljudno, a odločno vztrajate pri "pametnejšem" pristopu.

Prosimo, pošljite kakršne koli pripombe na LinkedIn.