Älykäs sopimusesittely: Hyperledger-kangas vs. MultiChain - Ethereum - Corda

On enemmän kuin yksi tapa laittaa koodi lohkoketjuun

Useimmissa keskusteluissa blokkiketjuista ei vie kauaa ajatusta "älykkäistä sopimuksista". Suositun mielikuvituksen mukaan älykkäät sopimukset automatisoivat osapuolten välisen vuorovaikutuksen toteuttamisen ilman, että vaaditaan luotettavaa välittäjää. Ilmaisemalla oikeussuhteet koodilla eikä sanoilla, ne lupaavat mahdollistaa liiketoimien suorittamisen suoraan ja ilman virheitä, olivatpa ne tarkoituksellisia vai eivät.

Teknisestä näkökulmasta älysopimus on jotain tarkempaa: tietokonekoodia, joka elää lohkoketjussa ja määrittelee säännöt kyseisen ketjun tapahtumille. Tämä kuvaus kuulostaa riittävän yksinkertaiselta, mutta sen takana piilee suuri vaihtelu näiden sääntöjen ilmaisussa, toteutuksessa ja validoinnissa. Kun valitset lohkoketjualustaa uudelle sovellukselle, tulee kysymykseen "Tukeeko tämä alusta älykkäitä sopimuksia?" ei ole oikea kysyä. Sen sijaan meidän on kysyttävä: "Millaisia ​​älykkäitä sopimuksia tämä alusta tukee?"

Tässä artikkelissa tavoitteeni on tutkia joitain suurimmista eroista älykkäiden sopimusten lähestymistapojen ja niiden edustamien kompromissien välillä. Teen tämän tarkastelemalla neljää suosittua yritysketjualustaa, jotka tukevat jonkinlaista mukautettua ketjun koodia. Ensinnäkin IBM: t Hyperledger-kangas, joka kutsuu sopimuksiaan "ketjukoodiksi". Toiseksi esittelemme MultiChain-alustamme älykkäät suodattimet versiossa 2.0. kolmanneksi Ethereum (ja sen lupa päätösvaltaisuus ja kolo spin-off), joka popularisoi älykkään sopimuksen nimeä. Ja lopuksi, R3 Corda, joka viittaa ”sopimuksiin” liiketoimissaan. Kaikesta erilaisesta terminologiasta huolimatta kaikki viittaavat samaan asiaan - sovelluskohtaiseen koodiin, joka määrittelee ketjun säännöt.

Ennen kuin jatkan eteenpäin, minun tulisi varoittaa lukijaa siitä, että suurin osa seuraavasta sisällöstä on luonteeltaan teknistä ja että hänellä on jonkinlainen tuntemus yleisistä ohjelmointi- ja tietokantakonsepteista. Hyväksi tai huonoksi, tätä ei voida välttää - ilman yksityiskohtiin tutustumista on mahdotonta tehdä tietoista päätöstä siitä, käytetäänkö lohkoketjua tiettyyn projektiin, ja (jos on) oikean tyyppistä lohkoketjua käytettäväksi.

Blockchain-perusteet

Aloitetaan jostain tilanteesta. Kuvittele sovellus, joka on jaettu useiden organisaatioiden kanssa ja joka perustuu taustalla olevaan tietokantaan. Perinteisessä keskitetyssä arkkitehtuurissa tätä tietokantaa isännöi ja hallinnoi yksi osapuoli, johon kaikki osallistujat luottavat, vaikka he eivät luottaisi toisiinsa. Tietokantaa modifioivia tapahtumia aloittavat vain tämän keskuspuolueen järjestelmät, usein vastauksena osallistujilta vastaanotetuille viesteille. Tietokanta tekee vain sen, mitä sanotaan, koska sovellukseen uskottiin epäsuorasti lähettää sille vain järkeviä tapahtumia.

Lohkoketjut tarjoavat vaihtoehtoisen tavan hallita jaettua tietokantaa ilman luotettavaa välittäjää. Lohkoketjussa jokainen osallistuja ajaa “solmua”, joka pitää kopion tietokannasta ja käsittelee itsenäisesti sitä modifioivia tapahtumia. Osallistujat tunnistetaan julkisilla avaimilla tai ”osoitteilla”, joista jokaisella on vastaava yksityinen avain, jonka vain henkilöllisyyden omistaja tuntee. Vaikka minkä tahansa solmun voi luoda tapahtumia, aloittajan yksityinen avain allekirjoittaa ne "digitaalisesti" alkuperänsä todistamiseksi.

Solmut muodostavat yhteyden toisiinsa vertaisverkolla, etenemällä nopeasti tapahtumia ja "lohkoja", joissa ne on aikaleimattu ja vahvistettu verkossa. Itse blockchain on kirjaimellisesti näiden lohkojen ketju, joka muodostaa tilatun lokin jokaisesta historiallisesta tapahtumasta. ”Konsensusalgoritmia” käytetään varmistamaan, että kaikki solmut pääsevät sopimukseen lohkon ketjun sisällöstä ilman keskitettyä hallintaa. (Huomaa, että osa tästä kuvauksesta ei koske Cordaa, jossa jokaisella solmulla on vain osittainen kopio tietokannasta eikä globaalia lohkoketjua. Puhumme siitä lisää myöhemmin.)

Periaatteessa mikä tahansa jaettu tietokantasovellus voidaan arkkitehtuurin avulla käyttää blockchain-ydintä. Mutta sen tekeminen luo joukon teknisiä haasteita, joita ei ole keskitetyssä skenaariossa:

• Transaktiosäännöt. Jos joku osallistuja voi muuttaa tietokantaa suoraan, miten varmistamme, että hän noudattaa sovelluksen sääntöjä? Mikä estää yhtä käyttäjää vahingoittamasta tietokannan sisältöä itsepalvelulla?
• determinismi. Kun nämä säännöt on määritelty, useat solmut soveltavat niitä useita kertoja käsitellessään tapahtumia oman tietokannan kopionsa varten. Kuinka varmistamme, että jokainen solmu saa täsmälleen saman tuloksen?
• Konfliktinesto. Ilman keskitettyä koordinointia miten voimme käsitellä kahta tapahtumaa, jotka molemmat seuraavat sovelluksen sääntöjä, mutta ovat silti ristiriidassa keskenään? Ristiriidat voivat johtua tahallisesta yrityksestä pelata järjestelmää, tai ne voivat olla huonon onnen ja ajoituksen viattomia seurauksia.

Joten mihin älykkäät sopimukset, älykkäät suodattimet ja ketjukoodi tulevat? Niiden päätarkoitus on työskennellä blockchain-infrastruktuurin kanssa näiden haasteiden ratkaisemiseksi. Älykkäät sopimukset ovat sovelluskoodin hajautettu vastine - sen sijaan, että ne toimisivat yhdessä keskeisessä paikassa, ne toimivat useissa solmukohdissa lohkoketjussa luomalla tai validoimalla tapahtumia, jotka muuttavat tietokannan sisältöä.

Aloitetaan transaktiosäännöillä, jotka ovat ensimmäinen näistä haasteista, ja katsotaan, kuinka ne ilmaistaan ​​vastaavasti kankaassa, MultiChainissa, Ethereumissa ja Cordassa.

Transaktiosäännöt

Transaktiosäännöt suorittavat tietyn toiminnon blockchain-pohjaisissa tietokannoissa - rajoittaen muunnokset jotka voidaan suorittaa kyseisen tietokannan tilassa. Tämä on välttämätöntä, koska kuka tahansa sen osallistuja voi aloittaa lohkoketjun transaktiot, ja nämä osallistujat eivät luota toisiinsa riittävästi voidakseen muuttaa tietokantaa haluamallaan tavalla.

Katsotaanpa kahta esimerkkiä siitä, miksi transaktiosääntöjä tarvitaan. Kuvittele ensin lohkoketju, joka on suunniteltu koottamaan ja leimaamaan osanottajien julkaisemia PDF-dokumentteja. Tässä tapauksessa kenelläkään ei pitäisi olla oikeutta poistaa tai muuttaa asiakirjoja, koska sen tekeminen vaarantaisi koko järjestelmän tarkoituksen - asiakirjan pysyvyyden. Toiseksi, harkitse ryhmäketjua, joka edustaa jaettua pääkirjaa, joka pitää kirjaa käyttäjien saldoista. Emme voi antaa osallistujan mielivaltaisesti lisätä omaa saldoaan tai ottaa muiden rahaa pois.

Tulot ja lähdöt

Lohkoketjualustamme tukeutuvat kahteen laajaan lähestymistapaan transaktiosääntöjen ilmaisemiseen. Ensimmäistä, jota kutsun “input-output model”, käytetään MultiChainissa ja Cordassa. Tässä transaktiot luettelevat nimenomaisesti tietokannan rivit tai “tilat”, jotka ne poistavat ja luovat, muodostaen joukon vastaavia “sisääntuloja” ja “lähtöjä”. Rivin muokkaaminen ilmaistaan ​​vastaavana toimintona poistamalla kyseinen rivi ja luomalla uusi sen tilalle.

Koska tietokantarivit poistetaan vain sisääntuloista ja luodaan vain ulostuloissa, jokaisen sisääntulon on "vietettävä" edellisen tapahtuman tuotos. Tietokannan nykyinen tila määritellään joukkoa "käyttämättä jääneitä tapahtumien tuotoksia" tai "UTXOs", ts. Aikaisempien tapahtumien tuotoksia, joita ei ole vielä käytetty. Tapahtumat voivat sisältää myös lisätietoja, nimeltään “metatiedot”, “komennot” tai “liitteet”, jotka eivät tule osaksi tietokantaa, mutta auttavat määrittelemään niiden merkityksen tai tarkoituksen.

Kun otetaan huomioon nämä kolme syöttö-, lähtö- ja metatietojoukkoa, tapahtuman pätevyys MultiChainissa tai Cordassa määritetään jollain koodilla, joka voi suorittaa mielivaltaisia ​​laskelmia näille ryhmille. Tämä koodi voi vahvistaa tapahtuman tai palauttaa virheen vastaavalla selityksellä. Voit ajatella panos-tuotos-mallia automatisoituna ”tarkastajana”, jolla on tarkistuslista, joka varmistaa, että tapahtumat seuraavat kaikkia sääntöjä. Jos tapahtuma epäonnistuu jollain näistä tarkastuksista, kaikki verkon solmut hylkäävät sen automaattisesti.

On huomattava, että huolimatta tulo- ja lähtömallin jakamisesta, MultiChain ja Corda toteuttavat sen hyvin eri tavalla. MultiChain-ohjelmassa ulostulot voivat sisältää sisältöä ja / tai tietoja JSON-, teksti- tai binaarimuodossa. Säännöt määritellään ”transaktiosuodattimissa” tai “stream suodattimissa”, jotka voidaan asettaa tarkistamaan kaikki tapahtumat tai vain tietyt varat tai tietoryhmät. Sen sijaan Cordan ulostulon ”tilaa” edustaa objekti Java- tai Kotlin-ohjelmointikielellä, jolla on määritellyt tietokentät. Cordan säännöt määritellään "sopimuksissa", jotka liitetään tiettyihin valtioihin, ja valtion sopimusta sovelletaan vain liiketoimiin, joissa tämä tila on sen tuloissa tai tuotoksissa. Tämä liittyy Cordan yrityksiin epätavallinen näkyvyysmalli, joissa liiketoimia voivat nähdä vain vastapuolet tai ne, joiden myöhempiin liiketoimiin ne vaikuttavat.

Sopimukset ja viestit

Toista lähestymistapaa, jota kutsun ”sopimusviestin malliksi”, käytetään Hyperledger Fabricissa ja Ethereumissa. Tällöin lohkoketjuun voidaan luoda useita "älykkäitä sopimuksia" tai "ketjukoodeja", ja jokaisella on oma tietokanta ja siihen liittyvä koodi. Sopimuksen tietokantaa voidaan muokata vain sen koodilla, eikä suoraan blockchain-tapahtumilla. Tämä suunnittelukaavio on samanlainen kuin koodin ja datan "kapselointi" olio-ohjelmointiin.

Tässä mallissa blockchain-tapahtuma alkaa sopimukseksi lähetetynä viestinä, jolla on joitain valinnaisia ​​parametreja tai tietoja. Sopimuksen koodi suoritetaan vastauksena viestiin ja parametreihin, ja se voi vapaasti lukea ja kirjoittaa omaa tietokantaansa osana tätä reaktiota. Sopimukset voivat myös lähettää viestejä muihin sopimuksiin, mutta eivät pääse suoraan toistensa tietokantoihin. Reliaatiotietokantojen kielellä sopimukset toimivat tahdonvastaiselta ”Tallennetut menettelyt”, joissa kaikki pääsy tietokantaan kulkee jonkin ennalta määritetyn koodin kautta.

Sekä Fabric että Quorum, Ethereumin muunnelma, vaikeuttavat tätä kuvaa sallimalla verkon määritellä useita “kanavia” tai “yksityisiä tiloja”. Tavoitteena on lieventää blockchain-luottamuksellisuuden ongelmaa luomalla erilliset ympäristöt, joista kukin on näkyvissä vain tietylle osallistujien alaryhmälle. Vaikka tämä kuulostaa teoriassa lupaavalta, tosiasiassa kunkin kanavan tai yksityisen valtion sopimukset ja tiedot ovat erillään muista sopimuksista. Tämän seurauksena älykkäiden sopimusten kannalta nämä ympäristöt vastaavat erillisiä lohkoketjuja.

Esimerkkejä säännöistä

Katsotaan kuinka toteuttaa transaktiosäännöt yhden omaisuuserän kirjanpidolle näiden kahden mallin avulla. Jokaisessa pääkirjarekisterimme tietokannassa on kaksi saraketta, jotka sisältävät omistajan osoitteen ja omistaman omaisuuden määrän. Panos-tuotos-mallissa liiketoimien on täytettävä kaksi ehtoa:

1. Tapahtuman tuotoksissa olevien varojen kokonaismäärän on vastattava panosten kokonaismäärää. Tämä estää käyttäjiä luomasta tai poistamasta rahaa mielivaltaisesti.
2. Jokaisen panoksen omistajan on allekirjoitettava jokainen tapahtuma. Tämä estää käyttäjiä käyttämästä toistensa rahaa ilman lupaa.

Yhdessä nämä kaksi ehtoa ovat kaikki tarvittavat yksinkertaisen mutta elinkelpoisen rahoitusjärjestelmän luomiseksi.

Sopimus-sanomamallissa omaisuuserän sopimus tukee ”maksa maksu” -viestiä, joka ottaa kolme parametria: lähettäjän osoitteen, vastaanottajan osoitteen ja lähetettävän määrän. Vastauksena sopimus suorittaa seuraavat neljä vaihetta:

1. Varmista, että lähettäjä on allekirjoittanut tapahtuman.
2. Tarkista, että lähettäjällä on riittävästi varoja.
3. Vähennä pyydetty määrä lähettäjän riviltä.
4. Lisää tämä määrä vastaanottajan riville.

Jos jompikumpi kahdessa ensimmäisessä vaiheessa olevista sekistä epäonnistuu, sopimus keskeytetään eikä maksua suoriteta.

Joten sekä tulo-lähtö- että sopimusviesti-mallit ovat tehokkaita tapoja määritellä transaktiosäännöt ja pitää jaettu tietokanta turvassa. Itse asiassa teoreettisella tasolla kutakin näistä malleista voidaan käyttää toisen simuloimiseksi. Käytännössä sopivin malli riippuu kuitenkin rakennettavasta sovelluksesta. Vaikuttaako jokainen tapahtuma muutamaan tai moniin tietoihin? Onko meidän kyettävä takaamaan liiketoimien riippumattomuus? Onko jokaisella tiedolla selkeä omistaja vai onko jotain globaalia tilaa jaettavaksi?

Täällä ei ole tutkittavana, miten vastausten tulisi vaikuttaa näiden kahden mallin valintaan. Mutta yleisenä suuntaviivana on kehitettäessä uutta blockchain-sovellusta, joten kannattaa yrittää ilmaista sen transaktiosäännöt molemmissa muodoissa ja nähdä mikä sopii luonnollisemmin. Ero ilmenee seuraavinä: (a) ohjelmoinnin helppous, (b) tallennusvaatimukset ja suorituskyky sekä (c) konfliktien havaitsemisen nopeus. Puhumme lisää tästä viimeisestä numerosta myöhemmin.

Sisäänrakennetut säännöt

Transaktiosääntöjen suhteen on yksi tapa, jolla MultiChain eroaa erityisesti Fabricista, Ethereumista ja Cordasta. Toisin kuin nämä muut alustat, MultiChainissa on useita sisäänrakennettuja abstrakteja, jotka tarjoavat joitain perusrakenteita lohkoketjuvetoisille sovelluksille ilman edellyttävät kehittäjät kirjoittavat oman koodinsa. Nämä abstraktiot kattavat kolme aluetta, joita yleisesti tarvitaan: (a) dynaamiset käyttöoikeudet, b) siirrettävät varat ja (c) tietojen varastointi.

Esimerkiksi, MultiChain hallitsee käyttöoikeuksia verkkoon yhdistämiseen, tapahtumien lähettämiseen ja vastaanottamiseen, omaisuuden tai streamien luomiseen tai muiden käyttäjien oikeuksien hallintaan. Useita vaihdettavia hyödykkeitä voidaan laskea liikkeelle, siirtää, siirtää eläkkeelle tai vaihtaa turvallisesti ja atomisesti. Ketjuun voidaan luoda mikä tahansa lukumäärä "suoratoistoja" ketju- tai ketjun ulkopuolisen datan julkaisemiseksi, indeksoimiseksi ja hakemiseksi JSON-, teksti- tai binaarimuodossa. Kaikki näiden abstraktioiden transaktiosäännöt ovat saatavilla suoraan laatikosta.

Kun kehität sovellusta MultiChainissa, on mahdollista sivuuttaa tämä sisäänrakennettu toiminto ja ilmaista tapahtumasääntöjä vain älykkäillä suodattimilla. Älykkäät suodattimet on kuitenkin suunniteltu toimimaan yhdessä sen sisäänrakennettujen abstraktioiden kanssa mahdollistamalla niiden oletuskäyttäytymisen rajoitettu räätälöityjä tapoja. Esimerkiksi tietyt järjestelmänvalvojat voivat valvoa tiettyjen toimien lupaa sen sijaan, että järjestelmänvalvoja suorittaa oletuskäyttäytymisen. Tiettyjen omaisuuserien siirto voi olla rajoitettu ajan kuluessa tai edellyttää tietyn määrän ylittävää lisähyväksyntää. Tietyn virtauksen tiedot voidaan validoida sen varmistamiseksi, että ne koostuvat vain JSON-rakenteista, joissa on vaadittavat kentät ja arvot.

Kaikissa näissä tapauksissa älykkäät suodattimet luovat lisävaatimuksia vahvistettaville tapahtumille, mutta eivät poistaa sisäänrakennetut yksinkertaiset säännöt. Tämä voi auttaa ratkaisemaan yhden blockchain-sovellusten keskeisistä haasteista: tosiasia, että jonkin ketjun koodin virhe voi johtaa tuhoisiin seurauksiin. Olemme nähneet loputtomia esimerkkejä tästä ongelmasta julkisessa Ethereumin lohkoketjussa, tunnetuimmin DAO: n raukeaminen ja Pariteetin monisignatuuriset virheet. Laajemmat tutkimukset ovat löytäneet suuren määrän yleisiä haavoittuvuuksia Ethereumin älykkäissä sopimuksissa, joiden avulla hyökkääjät voivat varastaa tai jäädyttää muiden kansojen varoja.

Tietenkin, MultiChain-älykkäät suodattimet voivat sisältää myös virheitä, mutta niiden seuraukset ovat rajoitetummat. Esimerkiksi sisäänrakennetut omaisuuden säännöt estävät yhtä käyttäjää käyttämästä toisen rahaa tai vahingossa tekemästä omaa rahaa katoamasta riippumatta siitä, mitä muuta logiikkaa älykäs suodatin sisältää. Jos virhe löytyy älykkäästä suodattimesta, se voidaan deaktivoida ja korvata korjatulla versiolla, kun taas kirjanpidon perus eheys on suojattu. Filosofisesti MultiChain on lähempänä perinteisiä tietokanta-arkkitehtuureja, joissa tietokantaalusta tarjoaa useita sisäänrakennettuja abstraktioita, kuten sarakkeita, taulukoita, hakemistoja ja rajoituksia. Sovelluskehittäjät voivat valinnaisesti koodata tehokkaampia ominaisuuksia, kuten liipaisimet ja tallennetut menettelyt, tapauksissa, joissa niitä todella tarvitaan.

Transaktiosäännöt	Kangas	moniketjuisille	Ethereum	corda
Malli	Sopimus-viesti	Panos-tuotos	Sopimus-viesti	Panos-tuotos
Takkasydämet	Ei eristetty	Luvat + varat + virrat	Ei eristetty	Ei eristetty

determinismi

Siirrymme seuraavaan showdown-osaamme. Riippumatta siitä, mitä lähestymistapaa valitsemme, lohkoketjusovelluksen räätälöidyt tapahtumasäännöt ilmaistaan ​​sovelluskehittäjien kirjoittamalla tietokonekoodilla. Ja toisin kuin keskitetyt sovellukset, tämä koodi suoritetaan useammin kuin kerran ja useammassa kuin yhdessä paikassa jokaiselle tapahtumalle. Tämä johtuu siitä, että useille lohkoketjusolmuille, jotka kuuluvat eri osallistujille, on jokaisen tarkistettava ja / tai suoritettava kyseinen tapahtuma itse.

Tämä toistuva ja tarpeeton koodin suorittaminen tuo käyttöön uuden vaatimuksen, jota harvoin esiintyy keskitetyissä sovelluksissa: determinismi. Laskennan yhteydessä determinismi tarkoittaa, että koodipala antaa aina saman vastauksen samoille parametreille, riippumatta siitä, missä ja milloin se suoritetaan. Tämä on ehdottoman välttämätöntä koodin kanssa, joka on vuorovaikutuksessa ryhmäketjun kanssa, koska ilman determinismia, ketjun solmujen välinen konsensus voi hajota katastrofaalisesti.

Katsotaanpa miten tämä näyttää käytännössä, ensin panos-tuotos-mallissa. Jos kahdella solmulla on erilainen mielipide tapahtuman pätevyydestä, toinen hyväksyy kyseistä tapahtumaa sisältävän lohkon ja toinen ei. Koska jokainen lohko linkittää nimenomaisesti takaisin edelliseen lohkoon, tämä luo pysyvän "haarukan" verkkoon, jolloin yksi tai useampi solmu ei hyväksy enemmistön mielipidettä koko lohkon ketjun sisällöstä siitä lähtien. Vähemmistön solmut poistetaan tietokannan kehittyvästä tilasta, eivätkä ne enää voi käyttää sovellusta tehokkaasti.

Katsotaanpa nyt mitä tapahtuu, jos konsensus hajoaa sopimusviesti-mallissa. Jos kahdella solmulla on erilainen mielipide siitä, kuinka sopimuksen tulisi vastata tiettyyn viestiin, tämä voi johtaa eroon tietokantojensa sisällössä. Tämä puolestaan ​​voi vaikuttaa sopimuksen vastaukseen tulevaisuuden viesteihin, mukaan lukien viestit, jotka se lähettää muihin sopimuksiin. Lopputulos on kasvava ero eri solmujen näkemyksissä tietokannan tilasta. ("State root" -kenttä Ethereum-lohkoissa varmistaa, että sopimuserottelujen erot johtavat välittömästi täysin katastrofaaliseen blockchain-haarukkaan sen sijaan, että ne vaarassa pysyä piilotettuna tietyn ajanjakson ajan.)

Ei-determinismin lähteet

Joten ei-determinismi blockchain-koodissa on selvästi ongelma. Mutta jos laskennan perusrakenteet, kuten aritmeettinen, ovat deterministisiä, mistä meidän on huolehdittava? No, osoittautuu, melko monia asioita:

• Ilmeisimmin satunnaislukugeneraattorit, koska määritelmän mukaan ne on suunniteltu tuottamaan erilainen tulos joka kerta.
• Nykyisen ajan tarkistaminen, koska solmut eivät käsittele tapahtumia täsmälleen samaan aikaan ja niiden kellot saattavat joka tapauksessa olla synkronoimattomia. (On edelleen mahdollista toteuttaa ajasta riippuvat säännöt viittaamalla aikaleimoihin itse blockchainissa.)
• Ulkoisten resurssien, kuten Internetin, levytiedostojen tai muiden tietokoneella käynnissä olevien ohjelmien, kysely. Näiden resurssien ei voida taata antavan aina samanlaisen vastauksen, ja ne voivat olla poissa käytöstä.
• Useiden koodinpalojen ajaminen rinnakkaisilla ”säikeillä”, koska tämä johtaa “kilpailuolosuhteisiin”, joissa näiden prosessien loppujärjestystä ei voida ennustaa.
• Suoritetaan kaikki liukulukulaskelmat, jotka voivat antaa jopa yksityiskohtaisesti erilaisia ​​vastauksia erilaisille tietokoneprosessoriarkkitehtuureille.

Neljässä blockchain-alustassamme käytetään useita erilaisia ​​lähestymistapoja näiden sudenkuoppia välttämiseksi.

Deterministinen toteutus

Aloitetaan Ethereumista, koska sen lähestymistapa on kaikkein ”puhdas”. Ethereum-sopimukset ilmaistaan ​​erikoiskäyttömuodossa, nimeltään “Ethereum bytecode”, jonka toteuttaa Ethereum Virtual Machine (“EVM”). Ohjelmoijat eivät kirjoita tavukoodeja suoraan, vaan tuottavat tai ”kääntävät” JavaScriptin kaltaiselta Solidity-ohjelmointikieleltä. (Muita kieliä oli aiemmin saatavilla, mutta ovat sittemmin olleet vanhentuneet.) Päättäväisyyden takaa se, että Solidity- ja Ethereum-tavukoodit eivät voi koodata ei-deterministisiä toimintoja - se on niin yksinkertaista.

MultiChain-suodattimet ja Corda-sopimukset valitsevat erilaisen lähestymistavan mukauttamalla olemassa olevat ohjelmointikielet ja suoritusympäristöt. MultiChain käyttää JavaScriptiä käynnissä Googlessa V8 moottori, joka muodostaa myös Chrome-selaimen ja Node.js-alustan ytimen, mutta ei-determinismin lähteet on poistettu käytöstä. Vastaavasti Corda käyttää Java tai Kotlin, jotka molemmat on koottu ”Java-tavukoodiin”, joka suoritetaan Java-virtuaalikoneessa (“JVM”). Toistaiseksi Corda käyttää Oraclen standardia ei-determinististä JVM: ää, mutta integrointi on käynnissä deterministinen versio. Sillä välin Cordan sopimuskehittäjien on huolehdittava siitä, etteivätkö ne määrittele epäkunnallisuutta koodissaan.

Kuinka Ethereumin purismi vertautuu MultiChainin ja Cordan evoluutio lähestymistapaan? Ethereumin tärkein etu on riskien minimointi - tarkoitukseen rakennettu virtuaalikone sisältää vähemmän todennäköisesti tahatonta ei-determinismin lähdettä. Vaikka tällainen valvonta voitaisiin korjata ohjelmistopäivityksellä, se häiritsisi ketjuja, jotka eivät riittävän epäonnistuneita kohtaamaan sitä. Ethereumin ongelmana on kuitenkin, että Solidity ja EVM muodostavat pienen ja syntyvän ekosysteemin laajemmassa ohjelmointikielen ja suoritusympäristön yhteydessä. Vertailun vuoksi JavaScript ja Java ovat kaksi parasta kieltä Githubissa, käyttävät miljardeja digitaalisia laitteita, ja niiden käyttöajat on optimoitu vuosikymmenien ajan. Oletettavasti tästä syystä julkinen Ethereumin lohkoketju harkitsee siirtymistä eWASM, syntyvän WebAssembly -standardin deterministinen haarukka.

Päättäväisyys hyväksynnällä

Hyperledger Fabric omaksuu determinismin täysin eri tavalla. Kun kankaassa “asiakas” -solmu haluaa lähettää viestin joihinkin ketjukoodeihin, se lähettää ensin viestin joillekin “endorser” -solmuille. Jokainen näistä solmuista suorittaa ketjukoodin itsenäisesti muodostaen lausunnon viesteistä vaikutus kyseisen ketjukoodin tietokannassa. Nämä mielipiteet lähetetään takaisin asiakkaalle yhdessä digitaalisen allekirjoituksen kanssa, joka muodollisesti muodostaa ”hyväksynnän”. Jos asiakas saa tarpeeksi suosituksia aiotusta tuloksesta, hän luo kyseisiä suosituksia sisältävän tapahtuman ja lähettää sen sisällyttämistä ketjuun.

Päättäväisyyden takaamiseksi jokaisella ketjukoodilla on ”hyväksymiskäytäntö”, joka määrittelee tarkalleen, minkä tyyppinen hyväksyntä vaaditaan liiketoimien pätevyyden varmistamiseksi. Esimerkiksi yhden ketjukoodin käytännössä voidaan todeta, että merkinnät vaaditaan ainakin puolelta blockchain-solmuista. Toinen voi vaatia hyväksyntää mistä tahansa kolmesta luotettavasta osapuolesta. Joka tapauksessa jokainen solmu voi itsenäisesti tarkistaa, onko tarvittavat suositukset vastaanotettu.

Erojen selventämiseksi determinismi useimmissa blockchain-alustoissa perustuu kysymykseen: "Mikä on seuraus tämän koodin suorittamisesta näihin tietoihin?" - ja meidän on oltava täysin varmoja siitä, että jokainen solmu vastaa tähän kysymykseen identtisesti. Kankaan determinismi sitä vastoin perustuu toiseen kysymykseen: "Onko riittävästi kannattajia yhtä mieltä tämän koodin suorittamisen tuloksesta näihin tietoihin?" Vastaaminen tähän on melko yksinkertainen laskentakysymys, ja ei-determinismissä ei ole tilaa hiipiä.

Kankaan päättämisellä päättämällä tavalla on useita mielenkiintoisia seurauksia. Ensinnäkin, ketjukoodi voidaan kirjoittaa monilla eri ohjelmointikielellä, koska niitä ei tarvitse mukauttaa determinismiin (Go, Java ja JavaScriptiä tuetaan tällä hetkellä). Toiseksi, ketjukoodi voi olla piilossa joiltakin ryhmäketjun osallistujilta, koska vain asiakkaiden ja tukijoiden on suoritettava se (itse tietokanta on maailmanlaajuisesti näkyvä). Viimeisenä, ja mikä tärkeintä, Fabric-ketjukoodi voi tehdä asioita, jotka ovat kiellettyjä muissa lohkoketjuympäristöissä, kuten tarkistaa sää online-web-sovellusliittymän avulla. Pahimmassa tapauksessa, kun jokainen hyväksyjä saa erilaisen vastauksen tästä sovellusliittymästä, asiakas ei pysty hankkimaan tarpeeksi suosituksia mihinkään tiettyyn tulokseen, eikä tapahtumaa tapahdu. (On huomattava, että Fabric-tiimin jäsenet edelleen suositella käyttämällä determinististä logiikkaa ketjukoodissa yllätyksien välttämiseksi.)

Mikä hinta Fabric maksaa tästä joustavuudesta? Jos ryhmäketjun tarkoituksena on poistaa välittäjät jaetusta tietokantapohjaisesta sovelluksesta, Fabricin luottamus kannattajiin vie suuren askeleen pois päämäärästä. Ketjun osallistujille ei enää riitä seuraamaan ketjukoodin sääntöjä - he tarvitsevat myös tiettyjä muita solmuja sopiakseen, että he ovat tehneet niin. Vielä pahempaa, haittaohjelmien kannattajien alajoukot voisivat hyväksyä tietokannan muutokset, jotka eivät seuraa ketjukoodia. Tämä antaa hyväksyjille paljon enemmän valtaa kuin tavallisissa lohkoketjuissa olevat validoijat, jotka voivat sensuroida tapahtumia, mutta eivät voi rikkoa salkkuketjun sääntöjä. Blockchain-sovelluskehittäjien on päätettävä, onko tällä vaihtoehdolla järkeä heidän tapauksensa suhteen.

determinismi	Kangas	moniketjuisille	Ethereum	corda
Malli	merkintöjen	Mukautettu ajoaika	Tarkoituksenmukaisesti rakennettu VM	Mukautettu ajoaika
kielet	Siirry + Java + JavaScript	JavaScript	kiinteys	Java + Kotlin
Koodin näkyvyys	Vastapuolet + ihailijat	Blockchain	Blockchain	Vastapuolet + huollettavien
tahdonvastaiselta	Ei	Kyllä	Kyllä	Ei (toistaiseksi)

Konfliktinesto

Toistaiseksi olemme keskustelleet siitä, kuinka erilaiset blockchain-alustat ilmaisevat transaktiosääntöjä koodissa ja kuinka ne varmistavat deterministisesti, että jokainen solmu soveltaa näitä sääntöjä identtisesti. Nyt on aika puhua esittelymme kolmannesta näkökohdasta: Kuinka kukin alusta käsittelee mahdollisuutta, että kaksi itsessään voimassa olevaa transaktiota ovat ristiriidassa keskenään? Kuvittele yksinkertaisimmassa esimerkissä, että Alicella on 10 dollaria pääkirjassa ja se lähettää kaksi tapahtumaa - toinen lähettää 8 dollaria Bobille ja toinen 7 dollaria Charlielle. On selvää, että vain yhden näistä liiketoimista voidaan antaa onnistua.

Kaksi mallia

Voimme aloittaa ryhmittelemällä MultiChainin ja Cordan lähestymistavan tähän ongelmaan. Kuten aiemmin on kuvattu, molemmat käyttävät panos-tuotos-mallia tapahtumien ja niiden sääntöjen esittämiseen, joissa kukin tapahtumasyöte kuluttaa aiemman tapahtuman tuotoksen. Tämä johtaa konfliktien estämisen yksinkertaiseen periaatteeseen: Jokainen tulos voidaan käyttää vain kerran. MultiChain-suodattimet ja Corda-sopimukset voivat luottaa omiin alustoihinsa tämän rajoituksen ehdottoman toteuttamiseksi. Koska Alisan 10 dollaria edustaa aikaisempi tapahtumatuotos, tämä yhden kulun sääntö estää hänen lähettämästä sitä automaattisesti sekä Bobille että Charlielle.

Tästä samankaltaisuudesta huolimatta on tärkeää huomata avainero siinä, kuinka MultiChain ja Corda estävät konfliktit. MultiChainissa jokainen solmu näkee jokaisen tapahtuman ja voi siten itsenäisesti varmistaa, että jokainen lähtö käytetään vain kerran. Tapahtumat, jotka suorittavat kaksinkertaisen kulutuksen aiemmin vahvistettuihin tapahtumiin verrattuna, hylätään välittömästi ja automaattisesti. Sitä vastoin Cordassa ei ole globaalia ryhmäketjua, joten ”notaareja” vaaditaan estämään nämä kaksinkertaiset kulut. Jokainen Cordan tulostila on osoitettu notaarille, jonka on allekirjoitettava kaikki tuotoksen tuottotapahtumat, mikä vahvistaa, että sitä ei ole käytetty aikaisemmin. Blokkiketjun osanottajien on luotettava notaareihin noudattavan tätä sääntöä rehellisesti, ja haitalliset notaarit voivat aiheuttaa tuhoa tahdolla. Kuten kankaassa tehtyjen merkintöjen kanssa, tämä “yhden kulutus palveluna”Suunnittelulla on etuja luottamuksellisuuden suhteen, mutta se tuo välittäjät uudestaan ​​vastapäätä lohkoketjun viljaa. (On tärkeää selventää, että osallistujaryhmät voivat johtaa Cordan notaareja konsensusalgoritmin avulla, joten pääkirjan eheys voidaan silti suojata yksittäisiltä huonoilta toimijoilta).

Siirrytään eteenpäin Ethereumiin. Muistuttamiseksi Ethereum käyttää sopimuksia ja viestejä tulojen ja lähtöjen sijaan. Tämän seurauksena transaktioristiriidat, kuten Alice: n kaksi maksua, eivät ole välittömästi näkyvissä blockchain-moottorille. Sen sijaan he havaitsevat ja estävät ne sopimus joka käsittelee tapahtumia sen jälkeen kun niiden järjestys on vahvistettu ketjussa. Kun käsitellään kutakin Alice-maksua, sopimus tarkistaa, onko hänen saldo riittävä. Jos Bobille 8 dollaria maksava tapahtuma tulee ensin, se käsitellään tavalliseen tapaan, jättäen Alicen tililleen 2 dollaria. Seurauksena on, että kun sopimus käsittelee toisen tapahtuman, joka maksaa 7 dollaria Charlielle, Alice puuttuu tarvittavista varoista ja kauppa keskeytyy.

Tuotokset vs. sopimukset

Toistaiseksi olemme nähneet kaksi erilaista tekniikkaa ristiriitaisten tapahtumien estämiseksi - yhden kulutuksen tuotokset MultiChainissa ja Cordassa ja sopimusperusteinen todentaminen Ethereumissa. Joten mikä on parempi?

Jotta autamme vastaamaan tähän kysymykseen, tarkastellaan esimerkkiä ”1-of-2-multiignature” -tili, jolla on 100 dollaria Gavinin ja Helenin puolesta ja joka antaa kummallekin heistä mahdollisuuden käyttää rahaa itsenäisesti. Gavin kehottaa hakemustaan ​​maksaa 80 dollaria Donnalle, ja muutamaa sekuntia myöhemmin Helen haluaa lähettää 40 dollaria Edwardille. Koska molemmille maksuille ei ole riittävästi varoja, nämä tapahtumat ovat väistämättä ristiriidassa. Jos molemmat transaktiot lähetetään, lopputulos määräytyy sen mukaan, mikä ensin siirtyy ketjuun. Huomaa, että toisin kuin Alice-esimerkki, tämä ristiriita on satunnainen, koska kukaan ei yritä rikkoa sovelluksen sääntöjä - heillä oli yksinkertaisesti epäonninen ajoitus.

Kun tarkastellaan tämän konfliktin todennäköisyyttä, avainkysymys on seuraava: Kun Gavin lähettää tapahtuman, kuinka kauan kestää Helenin solmu tietää, että hänen maksunsa voi epäonnistua? Mitä lyhyempi ajanjakso on, sitä todennäköisemmin Helen lopetetaan yrittämästä maksua, pelastaen hänet ja hänen hakemuksensa myöhemmältä yllätykseltä.

Tulo- ja lähtömallissa kaikki tapahtumien väliset ristiriidat näkyvät suoraan blockchain-alustalle, koska kaksi tapahtumaa yrittävät nimenomaisesti käyttää samaa aikaisempaa lähtöä. MultiChainissa tämä tapahtuu heti, kun Gavinin tapahtuma on edennyt Helenin solmuun, yleensä sekunnissa tai vähemmän. Cordassa toimittajan notaari kieltäytyy allekirjoittamasta Helenin kauppaa, koska se on jo allekirjoittanut Gavinin, joten Helen tietää heti, että hänen maksunsa epäonnistuu. (Vaikka Cordan notaari itsessään jaetaan, hänen on ehkä joutettava odottamaan muutama sekunti vastausta.) Kummassakaankaan tapauksessa ei tarvitse odottaa tapahtuman vahvistamista ja tilaamista ryhmäketjussa.

Entä Ethereumin malli? Tässä tapauksessa blockchain-alustalle ei ole välitöntä tietä, että syntyy ristiriita. Vaikka Helenin solmu voi nähdä Gavinin tapahtuman verkossa, se ei voi tietää miten tämä vaikuttaa Helenin omaan transaktioon, koska sen näkökulmasta nämä ovat yksinkertaisesti kaksi viestiä, jotka lähetetään samaan sopimukseen. Ehkä kymmenen sekuntia myöhemmin, kun ristiriitaisten tapahtumien lopullinen tilaus on vahvistettu lohkoketjussa, Helenin solmu laskee uudelleen todellisen odotetun lopputuloksen sijasta, ja hänen sovelluksensa päivittää näytön vastaavasti. Sillä välin sekä Gavin että Helen jätetään pimeään.

Mutta tästä ei pitäisi päätellä, että panos-tuotos-malli toimii aina parhaiten. Harkitse variaatiota esimerkkiskenaariossamme, jossa sekä Gavin että Helen pyytävät pienempiä 40 dollarin maksuja alkuperäisestä 100 dollarin saldosta samaan aikaan. Tulo- ja lähtömallissa nämä tapahtumat olisivat ristiriidassa, koska ne kuluttavat saman tietokantarivin, joka sisältää kyseisen 100 dollarin, ja vain yksi maksuista onnistuu. Mutta Ethereumissa molemmat transaktiot käsiteltäisiin onnistuneesti riippumatta niiden lopullisesta tilauksesta, koska tilillä on riittävästi varoja molemmille. Tässä tapauksessa Ethereum toteuttaa uskollisemmin Gavinin ja Helenin aikomukset.

Lue ja kirjoita sarjat

Lopuksi puhutaan Fabricista, jonka hyväksymispohjainen lähestymistapa on näiden kahden tekniikan yhdistelmä. Kuten aiemmin selitettiin, kun kankaan “asiakas” -solmu haluaa lähettää viestin sopimukselle, se pyytää ensin joitain hyväksyviä solmuja suorittamaan kyseisen viestin sen puolesta. Hyväksyvät solmut tekevät niin samalla tavalla kuin Ethereum - suorittavat sopimusta paikallista tietokantaansa vastaan ​​-, mutta tätä prosessia tarkkaillaan eikä sovelleta välittömästi. Jokainen hyväksyjä kirjaa rivisarjan, joka luetaan ja kirjoitetaan, ja merkitsee myös kyseisten rivien tarkan version tuona ajankohtana. Tähän versioitujen rivien "luku-kirjoitusjoukko" viitataan nimenomaisesti suosituksessa ja sisältyy asiakkaan lähettämään tapahtumaan.

Kangastapahtumien väliset ristiriidat ratkaistaan, kun niiden tilaukset on viimeistelty ketjussa. Jokainen solmu käsittelee jokaisen tapahtuman itsenäisesti, tarkistamalla hyväksyntäkäytännöt ja soveltamalla määritettyjä tietokantamuutoksia. Jos tapahtuma kuitenkin lukee tai kirjoittaa tietokantariviversion, jota aiempi tapahtuma on jo muokannut, kyseinen toinen tapahtuma jätetään huomioimatta. Palattuaan Aliceen ristiriitaisiin maksuihin Bobille ja Charlielle, molemmat näistä tapahtumista lukevat ja muuttavat samaa riviversiota, joka sisältää 10 dollaria, jolla Alice aloitti. Joten toinen kauppa keskeytetään turvallisesti ja automaattisesti.

Kankaan lähestymistapa konfliktien ratkaisuun toimii hienosti, mutta suorituskyvyn ja joustavuuden suhteen se yhdistää kahden edellisen mallin pahimman. Koska hyväksymiskirjat muuntavat transaktiot erityisiksi luku- ja kirjoitusjoukkoiksi, Gavinin ja Helenin samanaikaiset, mutta yhteensopivat 40 dollarin maksut johtaisivat konfliktiin, jonka Ethereum välttää. Fabric ei kuitenkaan saavuta syöttö- ja tulostusmallin nopeusetua, koska hyväksyjät suorittavat sopimuksia viimeisimmästä tietokannan versiosta, jonka vahvistaa lohkoketju, jättämättä huomioimatta vahvistettuja tapahtumia. Joten jos Helen aloittaa maksunsa muutaman sekunnin kuluttua Gavinista, mutta ennen kuin Gavinin on vahvistettu blockchainissa, Fabric luo ristiriitaisia ​​tapahtumia, joita puhdas input-output-malli välttää.

Konfliktinesto	Kangas	moniketjuisille	Ethereum	corda
Malli	Lue ja kirjoita sarjat	Yksi kulutus	Sopimustarkastukset	Yksi kulutus
Vahvistus	Itsenäinen	Itsenäinen	Itsenäinen	Luotettavat notaarit
Nopeus	~ 10 s (vahvistus)	~ 1s (leviäminen)	~ 10 s (vahvistus)	0 ~ 5s (notaari)

Monimutkainen valinta

Tässä kappaleessa tarkastelimme monia eri tapoja, joilla Corda, Ethereum, Fabric ja MultiChain käsittelevät "älykkäiden sopimusten" tai lohkoketjuun upotetun sovelluskoodin keskeisiä haasteita. Ja jokaisella alustalla on erilaisia ​​vastauksia kolmeen ydinkysymykseemme: Kuinka transaktiosäännöt esitetään? Kuinka koodi suoritetaan deterministisesti? Ja miten voimme estää konflikteja?

Joten kuka on voittaja älykkäästä sopimusnäyttelystämme? Tähän mennessä pitäisi olla selvää, että yksinkertaista vastausta ei ole. Jokainen alusta edustaa monimutkaista monisuuntaista kompromissia joustavuuden, yksinkertaisuuden, suorituskyvyn, hajottamisen, turvallisuuden ja luottamuksellisuuden välillä. Joten tietyn sovelluksen käyttöympäristön valinnan on aloitettava yksityiskohtaisella ymmärryksellä sovelluksen luottamusmallista, siihen liittyvistä liiketoimityypeistä ja niiden todennäköisistä ristiriitoista. Jos löydät jonkun, joka ajaa tiettyä älykkäättä sopimusratkaisua, ennen kuin hän tietää vastaukset näihin kysymyksiin, ehdotan kohteliaasti mutta tiukasti vaatiessaan heidän käyttävänsä "älykkäämpää" lähestymistapaa.

Ole hyvä ja lähetä kommentit LinkedIn.