Bakit Imposibleng Maraming Kaso sa Paggamit ng Matalinong Kontrata

Si Dr Gideon Greenspan ay ang tagapagtatag at CEO ng Coin Sciences, ang kumpanya sa likod ng MultiChain platform para sa mga pribadong blockchain.

Sa piraso ng Opinyon na ito, tinatalakay ng Greenspan ang mga smart contract na pinagana ng blockchain at kung bakit ang application na ito ng Technology ay maaaring nagdurusa mula sa napalaki na mga inaasahan.

Bilang developer ng isang sikat na platform ng blockchain, minsan ay tinatanong ako kung nasa roadmap ng MultiChain ang mga tulad-Ethereum na smart contract. Ang lagi kong sagot ay palaging: 'Hindi, o kahit na hindi pa'.

Ngunit sa mundong puno ng hype ng mga blockchain, matalinong mga kontrata ay ang lahat ng galit, kaya bakit kailanman hindi? Well, ang problema ay, habang alam na natin ngayon ang tatlong malakas na kaso ng paggamit para sa mga pinahihintulutang bitcoin-style blockchains (provenance, company recordkeeping at lightweight Finance), hindi pa natin nahahanap ang katumbas para sa Ethereum matalinong mga kontrata.

Hindi dahil T naiintindihan ng mga tao kung ano ang gusto nilang gawin ng mga smart contract. Sa halip, napakarami sa mga ideyang ito ay imposible. Kapag narinig ng matatalinong tao ang terminong "mga matalinong kontrata", malamang na tumakbo ang kanilang mga imahinasyon. Nagmumuni-muni sila ng mga pangarap ng autonomous intelligent na software, lumalabas sa mundo, kumukuha ng data para sa biyahe. Sa kasamaang palad, ang katotohanan ng mga matalinong kontrata ay mas makamundo.

Ang matalinong kontrata ay isang piraso ng code na naka-imbak sa isang blockchain, na na-trigger ng mga transaksyon sa blockchain at nagbabasa at nagsusulat ng data sa database ng blockchain na iyon. yun lang. talaga.

Ang isang matalinong kontrata ay isang magarbong pangalan lamang para sa code na tumatakbo sa isang blockchain, at nakikipag-ugnayan sa estado ng blockchain na iyon. At ano ang code? Ito ay Pascal, ito ay Python, ito ay PHP. Ito ay Java, ito ay Fortran, ito ay C++. Kung pinag-uusapan natin ang mga database, ito ay naka-imbak na mga pamamaraan na nakasulat sa isang extension ng SQL.

Ang lahat ng mga wikang ito ay pangunahing katumbas, nilulutas ang parehong uri ng mga problema sa parehong uri ng mga paraan. Siyempre, ang bawat isa ay may mga kalakasan at kahinaan - mababaliw kang bumuo ng website sa C o mag-compress ng HD na video sa Ruby. Ngunit sa prinsipyo, hindi bababa sa, magagawa mo kung gusto mo. Magbabayad ka lang ng mabigat na presyo sa mga tuntunin ng kaginhawahan, pagganap, at malamang, ang iyong buhok.

Ang problema sa mga matalinong kontrata ay T lamang ang mga inaasahan ng mga tao ay sobra-sobra, ito ay ang mga inaasahan na ito ay humahantong sa marami na gumugol ng oras at pera sa mga ideya na hindi posibleng maipatupad.

Mukhang may sapat na resource ang malalaking kumpanya para maglakbay sa mahabang landas – mula sa sandaling nakatagpo ang senior management ng bagong Technology, hanggang sa tunay na nauunawaan ang mga pakinabang at limitasyon ng teknolohiyang iyon. Marahil ang sarili nating karanasan ay makakatulong na paikliin ang panahong ito.

Sa nakalipas na siyam na buwan, marami kaming napag-usapan na mga kaso ng paggamit ng matalinong kontrata, at nakita namin ang aming sarili na tumutugon, paulit-ulit, na hindi talaga magagawa ang mga ito.

Bilang resulta, natukoy namin ang tatlong maling kuru-kuro sa smart contract na pinakakaraniwang pinanghahawakan. Ang mga ideyang ito ay T mali dahil ang Technology ay wala pa sa gulang, o ang mga tool ay hindi pa magagamit.

Sa halip, hindi nila naiintindihan ang mga pangunahing katangian ng code na nabubuhay sa isang database at tumatakbo sa isang desentralisadong paraan.

1. Pakikipag-ugnayan sa mga panlabas na serbisyo

Kadalasan, ang unang use case na iminungkahi ay isang matalinong kontrata na nagbabago sa gawi nito bilang tugon sa ilang panlabas na kaganapan. Halimbawa, isang Policy sa segurong pang-agrikultura na nagbabayad nang may kondisyon batay sa dami ng pag-ulan sa isang partikular na buwan.

Ang naisip na proseso ay ganito: Ang matalinong kontrata ay naghihintay hanggang sa paunang natukoy na oras, kinukuha ang ulat ng lagay ng panahon mula sa isang panlabas na serbisyo at kumikilos nang naaangkop batay sa data na natanggap.

Ang lahat ng ito ay mukhang simple, ngunit imposible rin. Bakit? Dahil ang blockchain ay isang consensus-based system, ibig sabihin ay gagana lamang ito kung ang bawat node ay umabot sa magkatulad na estado pagkatapos iproseso ang bawat transaksyon at block.

Ang lahat ng nangyayari sa isang blockchain ay dapat na ganap na deterministiko, na walang posibleng paraan para makapasok ang mga pagkakaiba. Sa sandaling hindi magkasundo ang dalawang tapat na node tungkol sa estado ng chain, ang buong sistema ay nagiging walang halaga.

Ngayon, alalahanin na ang mga matalinong kontrata ay iisa-isa na isinasagawa ng bawat node sa isang chain. Samakatuwid, kung ang isang matalinong kontrata ay kumukuha ng ilang impormasyon mula sa isang panlabas na pinagmulan, ang pagkuha na ito ay isinasagawa nang paulit-ulit at hiwalay ng bawat node. Ngunit dahil ang source na ito ay nasa labas ng blockchain, walang garantiya na ang bawat node ay makakatanggap ng parehong sagot.

Marahil ay babaguhin ng pinagmulan ang tugon nito sa pagitan ng mga kahilingan mula sa iba't ibang mga node, o marahil ay pansamantalang hindi ito magagamit. Alinmang paraan, nasira ang consensus at ang buong blockchain ay namatay.

Kaya, ano ang workaround? Sa totoo lang, ito ay medyo simple. Sa halip na isang matalinong kontrata na magpasimula ng pagkuha ng external na data, ONE o higit pang pinagkakatiwalaang partido ("oracles") ang gagawa ng transaksyon na nag-e-embed sa data na iyon sa chain. Ang bawat node ay magkakaroon ng kaparehong kopya ng data na ito, kaya ligtas itong magamit sa isang matalinong pagkalkula ng kontrata.

Sa madaling salita, itinutulak ng isang orakulo ang data sa blockchain sa halip na isang matalinong kontrata na kumukuha nito.

Pagdating sa mga matalinong kontrata na nagdudulot ng mga Events sa labas ng mundo, lumilitaw ang isang katulad na problema. Halimbawa, gusto ng marami ang ideya ng isang matalinong kontrata na tumatawag sa API ng bangko upang makapaglipat ng pera. Ngunit kung ang bawat node ay independiyenteng nagpapatupad ng code sa chain, sino ang may pananagutan sa pagtawag sa API na ito?

Kung ang sagot ay ONE node lamang, ano ang mangyayari kung ang partikular na node ay hindi gumana, sinadya o hindi? At kung ang sagot ay bawat node, mapagkakatiwalaan ba natin ang bawat node sa password ng API na iyon? At gusto ba talaga nating tawagin ang API nang daan-daang beses? Ang mas masahol pa, kung kailangang malaman ng matalinong kontrata kung matagumpay ang tawag sa API, babalik kami sa problema ng pagdepende sa external na data.

Gaya ng dati, available ang isang simpleng workaround. Sa halip na ang matalinong kontrata ay tumawag sa isang panlabas na API, gumagamit kami ng isang pinagkakatiwalaang serbisyo na sinusubaybayan ang estado ng blockchain at nagsasagawa ng ilang mga aksyon bilang tugon. Halimbawa, ang isang bangko ay maaaring aktibong manood ng blockchain at magsagawa ng mga paglilipat ng pera na sumasalamin sa mga on-chain na transaksyon. Ito ay walang panganib sa pinagkasunduan ng blockchain dahil ang chain ay gumaganap ng isang ganap na passive na papel.

Sa pagtingin sa dalawang workaround na ito, maaari tayong gumawa ng ilang mga obserbasyon.

Una, pareho silang nangangailangan ng isang pinagkakatiwalaang entity upang pamahalaan ang mga pakikipag-ugnayan sa pagitan ng blockchain at sa labas ng mundo. Bagama't ito ay teknikal na posible, pinapahina nito ang layunin ng isang desentralisadong sistema.

Pangalawa, ang mga mekanismong ginamit sa mga workaround na ito ay mga tuwirang halimbawa ng pagbabasa at pagsulat ng database. Ang isang orakulo na nagbibigay ng panlabas na impormasyon ay simpleng pagsusulat ng impormasyong iyon sa kadena. At ang isang serbisyo na sumasalamin sa estado ng blockchain sa totoong mundo ay walang ginagawa kundi ang pagbabasa mula sa chain na iyon. Sa madaling salita, ang anumang pakikipag-ugnayan sa pagitan ng isang blockchain at sa labas ng mundo ay limitado sa mga regular na operasyon ng database.

Pag-uusapan natin ang tungkol sa katotohanang ito mamaya.

2. Pagpapatupad ng mga on-chain na pagbabayad

Narito ang isa pang panukala na madalas nating marinig: ang paggamit ng matalinong kontrata para i-automate ang pagbabayad ng mga kupon para sa tinatawag na "smart BOND". Ang ideya ay para sa smart contract code na awtomatikong simulan ang mga pagbabayad sa mga naaangkop na oras, pag-iwas sa mga manu-manong proseso at paggarantiya na ang nagbigay ay hindi maaaring mag-default.

Siyempre, upang ito ay gumana, ang mga pondong ginamit sa pagbabayad ay dapat na nasa loob din ng blockchain, kung hindi, ang isang matalinong kontrata ay hindi maaaring magagarantiyahan ang kanilang pagbabayad.

Alalahanin na ang isang blockchain ay isang database lamang, sa kasong ito ay isang financial ledger na naglalaman ng inisyu na BOND at ilang pera. Kaya, kapag pinag-uusapan natin ang tungkol sa mga pagbabayad ng kupon, ang talagang pinag-uusapan natin ay ang mga pagpapatakbo ng database na awtomatikong nagaganap sa isang napagkasunduang oras.

Bagama't teknikal na magagawa ang automation na ito, dumaranas ito ng kahirapan sa pananalapi. Kung ang mga pondong ginamit para sa mga pagbabayad ng kupon ay kinokontrol ng matalinong kontrata ng bono, ang mga pagbabayad na iyon ay talagang magagarantiyahan. Ngunit nangangahulugan din ito na ang mga pondong iyon ay hindi magagamit ng nagbigay ng BOND para sa anumang bagay. At kung ang mga pondong iyon ay T nasa ilalim ng kontrol ng matalinong kontrata, walang paraan kung saan matitiyak ang pagbabayad.

Sa madaling salita, ang isang matalinong BOND ay maaaring walang kabuluhan para sa nagbigay, o walang kabuluhan para sa mamumuhunan. At kung iisipin mo ito, ito ay isang ganap na halatang kinalabasan.

Mula sa pananaw ng isang mamumuhunan, ang buong punto ng isang BOND ay ang kaakit-akit na rate ng pagbabalik nito, sa halaga ng ilang panganib ng default. At para sa nag-isyu, ang layunin ng bono ay makalikom ng mga pondo para sa isang produktibo ngunit medyo mapanganib na aktibidad, tulad ng pagtatayo ng bagong pabrika.

Walang paraan para magamit ng tagapagbigay ng BOND ang mga nalikom na pondo, habang sabay-sabay na ginagarantiyahan na babayaran ang mamumuhunan. Hindi dapat maging sorpresa na ang koneksyon sa pagitan ng panganib at pagbabalik ay hindi isang problema na malulutas ng mga blockchain.

3. Pagtatago ng kumpidensyal na data

Tulad ng isinulat ko tungkol sa dati, ang pinakamalaking hamon sa pag-deploy ng mga blockchain ay ang radikal na transparency na ibinibigay ng mga ito.

Halimbawa, kung 10 bangko ang magkakasamang nag-set up ng blockchain, at dalawa ang nagsasagawa ng bilateral na transaksyon, ito ay makikita kaagad ng iba pang walo. Bagama't may iba't ibang estratehiya para mabawasan ang problemang ito, walang nakakatalo sa pagiging simple at kahusayan ng isang sentralisadong database kung saan ang isang pinagkakatiwalaang administrator ay may ganap na kontrol sa kung sino ang makakakita kung ano.

Iniisip ng ilang tao na malulutas ng mga matalinong kontrata ang problemang ito. Nagsisimula sila sa katotohanan na ang bawat matalinong kontrata ay naglalaman ng sarili nitong miniature database, kung saan ito ay may ganap na kontrol. Ang lahat ng mga operasyon sa pagbasa at pagsulat sa database na ito ay pinapamagitan ng code ng kontrata, na ginagawang imposible para sa ONE kontrata na direktang basahin ang data ng isa pa. (Ang mahigpit na pagsasama sa pagitan ng data at code ay tinatawag na encapsulation, at ito ang pundasyon ng sikat na object-oriented programming paradigm).

Kaya, kung T ma-access ng ONE matalinong kontrata ang data ng iba, nalutas na ba natin ang problema sa pagiging kumpidensyal ng blockchain? Makatuwiran bang pag-usapan ang pagtatago ng impormasyon sa isang matalinong kontrata? Sa kasamaang palad, ang sagot ay hindi.

Dahil kahit na T mabasa ng ONE matalinong kontrata ang data ng iba, nakaimbak pa rin ang data na iyon sa bawat solong node sa chain. Para sa bawat kalahok sa blockchain, ito ay nasa memorya o disk ng isang sistema na ganap na kinokontrol ng kalahok na iyon. At walang makakapigil sa kanila sa pagbabasa ng impormasyon mula sa kanilang sariling sistema, kung at kailan nila pipiliin na gawin ito.

Ang pagtatago ng data sa isang matalinong kontrata ay halos kasing-secure ng pagtatago nito sa HTML code ng isang web page. Sigurado, T ito makikita ng mga regular na user ng web, dahil hindi ito ipinapakita sa window ng kanilang browser. Ngunit ang kailangan lang ay para sa isang web browser na magdagdag ng isang function na 'Tingnan ang Pinagmulan' (tulad ng mayroon silang lahat), at ang impormasyon ay nagiging pangkalahatang nakikita.

Katulad nito, para sa data na nakatago sa mga matalinong kontrata, kailangan lang ng isang tao na baguhin ang kanilang blockchain software upang ipakita ang buong estado ng kontrata, at ang lahat ng pagkakatulad ng lihim ay nawala.

Ang isang kalahating disenteng programmer ay maaaring gawin iyon sa loob ng isang oras o higit pa.

Para saan ang mga smart contract

Sa napakaraming bagay na hindi kayang gawin ng mga matalinong kontrata, ONE magtanong kung para saan ba talaga ang mga ito. Ngunit upang masagot ang tanong na ito, kailangan nating bumalik sa mga pangunahing kaalaman ng mga blockchain mismo. Upang recap, ang isang blockchain ay nagbibigay-daan sa isang database na maibahagi nang direkta at ligtas ng mga entity na hindi nagtitiwala sa isa't isa, nang hindi nangangailangan ng isang sentral na tagapangasiwa.

Ang mga Blockchain ay nagbibigay-daan sa disintermediation ng data, at ito ay maaaring humantong sa makabuluhang pagtitipid sa pagiging kumplikado at gastos.

Ang anumang database ay binago sa pamamagitan ng "mga transaksyon", na naglalaman ng isang hanay ng mga pagbabago sa database na iyon na dapat magtagumpay o mabigo sa kabuuan. Halimbawa, sa isang financial ledger, ang isang pagbabayad mula kay ALICE kay Bob ay kinakatawan ng isang transaksyon na (a) nagsusuri kung may sapat na pondo ALICE , (b) nagbawas ng isang dami mula sa account ni Alice at (c) nagdaragdag ng parehong dami sa ni Bob.

Sa isang regular na sentralisadong database, ang mga transaksyong ito ay nilikha ng isang pinagkakatiwalaang awtoridad. Sa kabaligtaran, sa isang nakabahaging database na hinihimok ng blockchain, ang mga transaksyon ay maaaring gawin ng sinuman sa mga gumagamit ng blockchain na iyon. At dahil ang mga user na ito ay hindi lubos na nagtitiwala sa isa't isa, ang database ay kailangang maglaman ng mga patakaran na naghihigpit sa mga transaksyon na ginawa.

Halimbawa, sa isang peer-to-peer na financial ledger, ang bawat transaksyon ay dapat panatilihin ang kabuuang dami ng mga pondo, kung hindi, ang mga kalahok ay maaaring malayang magbigay sa kanilang sarili ng maraming pera ayon sa gusto nila.

Maaaring isipin ng ONE ang iba't ibang paraan ng pagpapahayag ng mga panuntunang ito, ngunit sa ngayon ay may dalawang nangingibabaw na paradigma, na inspirasyon ng Bitcoin at Ethereum, ayon sa pagkakabanggit. Ang pamamaraan ng Bitcoin , na maaari nating tawaging "mga hadlang sa transaksyon", ay sinusuri ang bawat transaksyon sa mga tuntunin ng: (a) ang mga entry sa database na tinanggal ng transaksyong iyon at (b) ang mga entry na nilikha.

Sa isang financial ledger, isinasaad ng panuntunan na ang kabuuang dami ng mga pondo sa mga tinanggal na entry ay kailangang tumugma sa kabuuan sa mga nilikha. (Isinasaalang-alang namin na ang pagbabago ng isang umiiral na entry ay katumbas ng pagtanggal sa entry na iyon at paglikha ng ONE sa lugar nito).

Ang pangalawang paradigm, na nagmula sa Ethereum, ay mga matalinong kontrata. Ito ay nagsasaad na ang lahat ng mga pagbabago sa data ng isang kontrata ay dapat gawin sa pamamagitan ng code nito. (Sa konteksto ng mga tradisyunal na database, maaari nating isipin ito bilang isang ipinatupad na naka-imbak na pamamaraan.) Upang baguhin ang data ng isang kontrata, ang mga gumagamit ng blockchain ay nagpapadala ng mga kahilingan sa code nito, na tumutukoy kung at paano tutuparin ang mga kahilingang iyon.

Tulad ng halimbawang ito, ang matalinong kontrata para sa isang financial ledger ay gumaganap ng parehong tatlong gawain bilang administrator ng isang sentralisadong database: pagsuri ng sapat na pondo, pagbabawas mula sa ONE account at pagdaragdag sa isa pa.

Parehong mabisa ang mga paradigm na ito, at bawat isa ay may mga pakinabang at disadvantage nito. Upang buod, ang mga hadlang sa transaksyon sa istilo ng bitcoin ay nagbibigay ng higit na mahusay na pagkakatugma at pagganap, habang ang mga smart na kontrata sa istilo ng Ethereum ay nag-aalok ng higit na kakayahang umangkop.

Kaya't bumalik sa tanong kung para saan ang mga matalinong kontrata: Ang mga matalinong kontrata ay para sa mga kaso ng paggamit ng blockchain na T maipapatupad nang may mga hadlang sa transaksyon.

Dahil sa pamantayang ito para sa paggamit ng mga matalinong kontrata, wala pa akong nakikitang malakas na kaso ng paggamit para sa mga pinapahintulutang blockchain na kwalipikado.

Ang lahat ng nakakahimok na blockchain na mga application na alam ko ay maaaring ipatupad sa bitcoin-style na mga transaksyon, na maaaring pangasiwaan ang pagpapahintulot at pangkalahatang pag-iimbak ng data, pati na rin ang paglikha ng asset, paglilipat, escrow, palitan at pagkasira. Gayunpaman, lumalabas pa rin ang mga bagong kaso ng paggamit, at T ako magtataka kung ang ilan ay nangangailangan ng kapangyarihan ng mga matalinong kontrata. O, hindi bababa sa, isang extension ng Bitcoin paradigm.

Anuman ang magiging sagot, ang susi na dapat tandaan ay ang mga matalinong kontrata ay ONE paraan lamang para sa paghihigpit sa mga transaksyong ginawa sa isang database.

Ito ay walang alinlangan na isang kapaki-pakinabang na bagay, at ito ay mahalaga sa paggawa ng database na ligtas para sa pagbabahagi. Ngunit ang mga matalinong kontrata ay walang magagawa, at tiyak na hindi sila makakatakas sa mga hangganan ng database kung saan sila nakatira.

Larawan ng lapis at pambura sa pamamagitan ng Shutterstock