Hoiduge võimatust nutikast lepingust

Kolm levinumat nutika lepingu väärarusaama

Populaarse plokiahela platvormi arendajatena küsitakse meilt mõnikord, kas Ethereumi-laadsed nutikad lepingud on saadaval MultiCin teekaart. Vastus, mille ma alati annan, on: ei, või vähemalt mitte veel.

Kuid plokiahelate ülekäte täis maailmas on nutikad lepingud moes, miks siis mitte kunagi? Probleem on selles, et kuigi me teame nüüd kolme tugevat kasutusjuhtu lubatud Bitcoini-tüüpi plokiahelate jaoks (päritolu, ettevõtetevahelised dokumendid ja kerge rahandus), ei ole me veel leidnud Ethereumi stiilis nutikate lepingute jaoks ekvivalendit.

Asi pole selles, et inimestel pole ideid selle kohta, mida nad nutikate lepingutega teha tahavad. Pigem on asi selles, et neid ideid on nii palju on lihtsalt võimatud. Näete, kui targad inimesed kuulevad mõistet "targad lepingud", kipub nende kujutlusvõime lendama. Nad loovad unistused autonoomsest intelligentsest tarkvarast, mis läheb maailma ja võtab selle andmed kaasa.

Kahjuks on arukate lepingute tegelikkus palju igapäevasem kui kõik see:

Nutikas leping on kooditükk, mis salvestatakse plokiahelasse, käivitatakse plokiahela tehingute kaudu ning mis loeb ja kirjutab andmeid selle plokiahela andmebaasi.

See on kõik. Tõesti. Nutikas leping on lihtsalt väljamõeldud nimi koodile, mis töötab plokiahelas ja suhtleb selle plokiahela olekuga. Ja mida is kood? See on Pascal, see on Python, see on PHP. See on Java, see on Fortran, see on C++. Kui me räägime andmebaasidest, siis see on salvestatud protseduurid kirjutatud SQL-i laienduses. Kõik need keeled on põhimõtteliselt samaväärsed, lahendades samu probleeme samal viisil. Muidugi on kõigil oma tugevad ja nõrgad küljed – oleksite hull, kui ehitaksite veebisaidi C-vormingus või tihendaksite HD-videot Ruby-vormingus. Aga vähemalt põhimõtteliselt võiks, kui tahaks. Maksaksite lihtsalt kallist hinda mugavuse, jõudluse ja üsna tõenäoliselt oma juuste eest.

Nutikate lepingute probleem ei seisne ainult selles, et inimeste ootused on ülepaisutatud. Need ootused sunnivad paljusid kulutama aega ja raha ideedele, mida pole võimalik ellu viia. Näib, et suurtel ettevõtetel on piisavalt ressursse, et läbida pikk tee – alates hetkest, mil tippjuhtkond puutub kokku uue tehnoloogiaga, kuni selle tehnoloogia eeliste ja piirangute tõeliselt mõistmiseni. Võib-olla aitab meie enda kogemus seda aega lühendada.

Viimase üheksa kuu jooksul on meile esitatud palju nutikaid lepingute kasutamise juhtumeid ja oleme ikka ja jälle avastanud, et neid lihtsalt ei saa teha. Selle tulemusena oleme tuvastanud kolm kõige sagedamini levinud nutikat lepingut puudutavat väärarusaamu. Need ideed ei ole valed, kuna tehnoloogia on ebaküps või tööriistad pole veel saadaval. Pigem saavad nad sellest valesti aru andmebaasis elava ja detsentraliseeritud viisil töötava koodi põhiomadused.

Väliste teenustega ühenduse võtmine

Sageli on esimene väljapakutud kasutusjuht nutikas leping, mis muudab oma käitumist vastuseks mõnele välisele sündmusele. Näiteks põllumajanduskindlustus, mis makstakse välja tingimuslikult vastavalt konkreetse kuu sademete hulgale. Väljamõeldud protsess käib umbes nii: nutikas leping ootab etteantud ajani, hangib välisteenusest ilmateate ja käitub saadud andmete põhjal vastavalt.

See kõik kõlab piisavalt lihtsalt, kuid see on ka võimatu. Miks? Kuna plokiahel on konsensusepõhine süsteem, mis tähendab, et see töötab ainult siis, kui iga sõlm jõuab pärast iga tehingu ja ploki töötlemist identsesse olekusse. Kõik, mis plokiahelas toimub, peab olema täielikult deterministlik, ilma et erinevused saaksid sisse hiilida. Hetkel, kui kaks ausat sõlme on ahela oleku suhtes eriarvamusel, muutub kogu süsteem väärtusetuks.

Tuletage nüüd meelde, et nutikaid lepinguid täidavad ahela kõik sõlmed iseseisvalt. Seega, kui nutikas leping hangib osa teabe välisest allikast, teostab see otsingu iga sõlm korduvalt ja eraldi. Kuid kuna see allikas on väljaspool plokiahelat, ei ole mingit garantiid, et iga sõlm saab sama vastuse. Võib-olla muudab allikas oma vastust eri sõlmede päringute vahelise aja jooksul või muutub see ajutiselt kättesaamatuks. Mõlemal juhul konsensus katkeb ja kogu plokiahel sureb.

Mis on lahendus? Tegelikult on see üsna lihtne. Nutika lepingu asemel, mis algatab väliste andmete otsimise, loob üks või mitu usaldusväärset osapoolt ("oraakel") tehingu, mis manustab need andmed ahelasse. Igal sõlmel on nendest andmetest identne koopia, nii et neid saab nutika lepingu arvutamisel turvaliselt kasutada. Teisisõnu, oraakel vajutab andmed plokiahelasse, mitte nutikasse lepingusse tõmmates see sisse.

Kui rääkida nutikatest lepingutest, mis põhjustavad sündmusi välismaailmas, ilmneb sarnane probleem. Näiteks meeldib paljudele nutika lepingu idee, mis helistab raha ülekandmiseks panga API-le. Aga kui iga sõlm täidab ahelas koodi iseseisvalt, siis kes vastutab selle API kutsumise eest? Kui vastus on ainult üks sõlm, mis juhtub siis, kui see konkreetne sõlm tõrkeb, kas tahtlikult või mitte? Ja kui vastus on iga sõlm, kas me saame usaldada selle API parooli igale sõlmele? Ja kas me tõesti tahame, et API-d kutsutaks sadu kordi? Veelgi hullem, kui nutikas leping peab teadma, kas API-kõne õnnestus, oleme kohe tagasi välisandmetest sõltumise probleemi juurde.

Nagu varemgi, on saadaval lihtne lahendus. Selle asemel, et nutikas leping kutsuks välist API-d, kasutame usaldusväärset teenust, mis jälgib plokiahela olekut ja teeb vastuseks teatud toiminguid. Näiteks võib pank ennetavalt jälgida plokiahelat ja teha rahaülekandeid, mis peegeldavad ahelasiseseid tehinguid. See ei ohusta plokiahela konsensust, kuna kett mängib täiesti passiivset rolli.

Vaadates neid kahte lahendust, saame teha mõned tähelepanekud. Esiteks vajavad nad mõlemad usaldusväärset üksust, et hallata plokiahela ja välismaailma vahelisi koostoimeid. Kuigi see on tehniliselt võimalik, õõnestab see detsentraliseeritud süsteemi eesmärki. Teiseks on nendes lahendustes kasutatud mehhanismid lihtsad näited andmebaasi lugemine ja kirjutamine. Oraakel, mis pakub välist teavet, kirjutab selle teabe lihtsalt ahelasse. Ja teenus, mis peegeldab plokiahela olekut reaalses maailmas, ei tee muud, kui loeb sellest ahelast. Teisisõnu, igasugune interaktsioon plokiahela ja välismaailma vahel on piiratud tavapäraste andmebaasitoimingutega. Sellest faktist räägime hiljem lähemalt.

Ahelasiseste maksete jõustamine

Siin on veel üks ettepanek, mida kipume palju kuulma: nutika lepingu kasutamine nn nutika võlakirja kupongide maksmise automatiseerimiseks. Idee on selles, et nutika lepingu kood algataks maksed automaatselt õigel ajal, vältides käsitsi protsesse ja garanteerides, et väljastaja ei saaks makseid teha.

Muidugi, et see toimiks, peavad maksete tegemiseks kasutatud vahendid elama ka plokiahela sees, vastasel juhul ei saaks nutikas leping nende maksmist kuidagi garanteerida. Tuletage nüüd meelde, et plokiahel on lihtsalt andmebaas, antud juhul finantsreskontra, mis sisaldab emiteeritud võlakirja ja natuke sularaha. Nii et kui me räägime kupongimaksetest, siis tegelikult räägime andmebaasitoimingutest, mis toimuvad automaatselt kokkulepitud ajal.

Kuigi see automatiseerimine on tehniliselt teostatav, on sellel rahalised raskused. Kui kupongimakseteks kasutatavaid vahendeid kontrollib võlakirja nutikas leping, siis saab neid makseid tõepoolest tagada. Kuid see tähendab ka neid vahendeid võlakirjade väljastaja ei saa seda kasutada millekski muuks. Ja kui need vahendid ei ole nutika lepingu kontrolli all, siis makset ei saa kuidagi garanteerida.

Teisisõnu, nutikas võlakiri on kas emitendi jaoks või investori jaoks mõttetu. Ja kui järele mõelda, on see täiesti ilmne tulemus. Investori vaatenurgast on võlakirja kogu mõte selle atraktiivne tootlus, mille hinnaks on teatud maksejõuetuse risk. Ja emitendi jaoks on võlakirja eesmärk koguda raha tootlikuks, kuid mõnevõrra riskantseks tegevuseks, näiteks uue tehase ehitamiseks. Võlakirjaemitendil puudub võimalus kaasatud vahendeid kasutada, tagades samal ajal investori tagasimaksmise. See ei tohiks tulla üllatusena seos riski ja tulu vahel ei ole probleem, mida plokiahelad suudavad lahendada.

Konfidentsiaalsete andmete peitmine

Nagu ma olen varem kirjutatud, on plokiahelate juurutamise suurim väljakutse nende pakutav radikaalne läbipaistvus. Näiteks kui kümme panka loovad koos plokiahela ja kaks teevad kahepoolset tehingut, on see ülejäänud kaheksale kohe nähtav. Kuigi selle probleemi leevendamiseks on erinevaid strateegiaid, ei ületa ükski tsentraliseeritud andmebaasi lihtsust ja tõhusust, kus usaldusväärsel administraatoril on täielik kontroll selle üle, kes mida näeb.

Mõned inimesed arvavad, et nutikad lepingud võivad selle probleemi lahendada. Need algavad sellest, et iga nutika leping sisaldab oma miniatuurset andmebaasi, mille üle tal on täielik kontroll. Kõik lugemis- ja kirjutamistoimingud selles andmebaasis on vahendatud lepingu koodiga, mistõttu ei ole ühel lepingul võimalik teise isiku andmeid otse lugeda. (Seda tihedat andmete ja koodi vahelist seost nimetatakse kapseldamiseks ja see on populaarse vundament objektorienteeritud programmeerimine paradigma.)

Nii et kui üks nutikas leping ei pääse ligi teise andmetele, kas oleme lahendanud plokiahela konfidentsiaalsuse probleemi? Kas nutikas lepingus on mõtet rääkida info peitmisest? Kahjuks on vastus eitav. Sest isegi kui üks nutikas leping ei saa teise andmeid lugeda, salvestatakse need andmed ikkagi ahela igasse sõlme. Iga plokiahelas osaleja jaoks on see a mälus või kettal süsteem, mida see osaleja täielikult kontrollib. Ja miski ei takista neil oma süsteemist teavet lugemast, kui ja millal nad seda soovivad.

Andmete peitmine nutikas lepingus on umbes sama turvaline kui nende peitmine veebilehe HTML-koodi. Muidugi ei näe tavalised veebikasutajad seda, sest seda ei kuvata nende brauseriaknas. Kuid piisab vaid sellest, et veebibrauser lisab funktsiooni „View Source” (nagu neil kõigil on) ja peidetud teave muutub üldiselt nähtavaks. Sarnaselt nutikatesse lepingutesse peidetud andmete puhul piisab sellest, kui keegi muudaks oma plokiahela tarkvara, et kuvada lepingu täielik olek, ja igasugune saladuse näit kaob. Pool korralik programmeerija saaks sellega hakkama umbes tunniga.

Milleks targad lepingud on

Kuna nutikad lepingud ei suuda nii palju asju teha, võib küsida, milleks need tegelikult on. Kuid sellele küsimusele vastamiseks peame minema tagasi plokiahelate endi põhialuste juurde. Kokkuvõtteks võib öelda, et plokiahel võimaldab andmebaasi otse ja turvaliselt jagada üksustele, kes üksteist ei usalda, ilma et oleks vaja keskadministraatorit. Plokiahelad võimaldavad andmete vahet ja see võib viia keerukuse ja kulude märkimisväärse kokkuhoiuni.

Iga andmebaasi muudetakse „tehingute” kaudu, mis sisaldavad selle andmebaasi muudatuste komplekti, mis peavad tervikuna õnnestuma või ebaõnnestuma. Näiteks finantsreskontras esindab Alice'i makset Bobile tehing, mis (a) kontrollib, kas Alice'il on piisavalt raha, (b) arvab summa Alice'i kontolt maha ja (c) lisab sama koguse Bobi kontole. .

Tavalises tsentraliseeritud andmebaasis loob need tehingud üks usaldusväärne asutus. Seevastu plokiahela juhitud jagatud andmebaasis saavad tehinguid luua kõik selle plokiahela kasutajad. Ja kuna need kasutajad üksteist täielikult ei usalda, peab andmebaas sisaldama reegleid, mis piiravad sooritatavaid tehinguid. Näiteks peer-to-peer finantsreskontras peab iga tehing säilitama raha kogusumma, vastasel juhul võivad osalejad anda endale vabalt nii palju raha, kui neile meeldib.

Võib ette kujutada erinevaid viise nende reeglite väljendamiseks, kuid praegu on kaks domineerivat paradigmat, mis on inspireeritud vastavalt Bitcoinist ja Ethereumist. Bitcoini meetod, mida võiksime nimetada "tehingupiiranguteks", hindab iga tehingut: (a) selle tehinguga kustutatud andmebaasikirjete ja (b) loodud kirjete alusel. Finantsreskontras näeb reegel ette, et kustutatud kirjete vahendite kogusumma peab ühtima loodud kirjete kogusummaga. (Leiame, et olemasoleva kirje muutmine on samaväärne selle kirje kustutamisega ja selle asemele uue loomisega.)

Teine paradigma, mis pärineb Ethereumist, on nutikad lepingud. See sätestab, et kõik lepingu andmete muudatused peavad toimuma selle koodi järgi. (Traditsiooniliste andmebaaside kontekstis võime seda mõelda kui jõustunud salvestatud protseduur.) Lepingu andmete muutmiseks saadavad plokiahela kasutajad Taotlusi oma koodile, mis määrab, kas ja kuidas neid taotlusi täita. Nagu see näide, täidab finantsreskontra nutikas leping samu kolme ülesannet, mis tsentraliseeritud andmebaasi haldaja: piisava raha olemasolu kontrollimine, ühelt kontolt mahaarvamine ja teisele lisamine.

Mõlemad paradigmad on tõhusad ja mõlemal on oma eelised ja puudused, nagu ma olen teinud eelnevalt põhjalikult arutatud. Kokkuvõtteks võib öelda, et Bitcoini-stiilis tehingupiirangud pakuvad suurepärast samaaegsust ja jõudlust, samas kui Ethereumi stiilis nutikad lepingud pakuvad suuremat paindlikkust. Niisiis, kui tulla tagasi küsimuse juurde, milleks nutikad lepingud on mõeldud:

Nutikad lepingud on mõeldud plokiahela kasutusjuhtudeks, mida ei saa rakendada tehingupiirangutega.

Arvestades seda nutikate lepingute kasutamise kriteeriumi, ei ole ma veel näinud tugevat kasutusjuhtumit lubatud plokiahelate jaoks, mis kvalifitseeruksid. Kõiki mulle tuttavaid veenvaid plokiahela rakendusi saab rakendada Bitcoini-stiilis tehingutega, mis saavad hakkama lubade andmise ja üldise andmete salvestamisega, samuti varade loomise, ülekandmise, tingdeponeerimise, vahetamise ja hävitamisega. Sellegipoolest ilmub endiselt uusi kasutusjuhtumeid ja ma ei imestaks, kui mõned do nõuavad nutikate lepingute jõudu. Või vähemalt Bitcoini paradigma laiendus.

Ükskõik, milline vastus ka poleks, tuleb meeles pidada, et nutikad lepingud on lihtsalt üks meetod andmebaasis tehtavate tehingute piiramiseks. See on kahtlemata kasulik asi ja oluline selle andmebaasi jagamiseks turvaliseks muutmiseks. Kuid nutikad lepingud ei saa midagi muud teha ja kindlasti ei saa nad välja pääseda selle andmebaasi piiridest, milles nad asuvad.

Palun postitage kõik kommentaarid LinkedInis.