Atenție la contractul inteligent imposibil

Cele mai comune trei concepții greșite privind contractele inteligente

În calitate de dezvoltatori ai unei platforme blockchain populare, uneori suntem întrebați dacă contractele inteligente asemănătoare Ethereum sunt pe multicatenari foaie de parcurs. Răspunsul pe care îl dau întotdeauna este: nu, sau cel puțin nu încă.

Dar în lumea plină de hype a blockchain-urilor, contractele inteligente sunt la furie, așa că de ce nu? Ei bine, problema este că, deși acum cunoaștem trei cazuri de utilizare puternice pentru blockchain-urile permise în stil Bitcoin (proveniență, înregistrări inter-companie și finanțare ușoară), încă nu găsim echivalentul pentru contractele inteligente în stil Ethereum.

Nu este că oamenilor le lipsește ideile despre ce vor să facă contractele inteligente. Mai degrabă, sunt atât de multe dintre aceste idei sunt pur și simplu imposibile. Vedeți, atunci când oamenii inteligenți aud termenul „contracte inteligente”, imaginația lor tinde să se dezlănțuie. Ei evocă vise de software inteligent autonom, care pleacă în lume, luând datele sale pentru plimbare.

Din păcate, realitatea contractelor inteligente este mult mai banală decât toate acestea:

Un contract inteligent este o bucată de cod care este stocată pe un blockchain, declanșat de tranzacțiile blockchain și care citește și scrie date în baza de date a acelui blockchain.

Asta este. Într-adevăr. Un contract inteligent este doar un nume de lux pentru codul care rulează pe un blockchain și interacționează cu starea acelui blockchain. Si ce is cod? Este Pascal, este Python, este PHP. Este Java, este Fortran, este C++. Dacă vorbim de baze de date, este proceduri stocate scris într-o extensie a SQL. Toate aceste limbi sunt fundamental echivalente, rezolvând aceleași tipuri de probleme în aceleași moduri. Desigur, fiecare are punctele sale forte și punctele sale slabe – ați fi nebun să construiți un site web în C sau să comprimați videoclipuri HD în Ruby. Dar, în principiu, cel puțin, ai putea dacă ai vrea. Pur și simplu ai plăti un preț mare în ceea ce privește comoditatea, performanța și, probabil, părul tău.

Problema cu contractele inteligente nu este doar că așteptările oamenilor sunt exagerate. Este faptul că aceste așteptări îi fac pe mulți să cheltuiască timp și bani pe idei care nu pot fi puse în aplicare. Se pare că companiile mari au suficiente resurse pentru a parcurge un drum lung – din momentul în care managementul superior întâlnește o nouă tehnologie, până când avantajele și limitările acestei tehnologii sunt cu adevărat înțelese. Poate că propria noastră experiență poate ajuta la scurtarea acestui timp.

În ultimele nouă luni, ni s-au prezentat multe cazuri de utilizare a contractelor inteligente și ne-am trezit să răspundem, în repetate rânduri, că pur și simplu nu se pot face. Drept urmare, am identificat cele trei concepții greșite privind contractele inteligente care sunt cel mai frecvent susținute. Aceste idei nu sunt greșite deoarece tehnologia este imatură sau instrumentele nu sunt încă disponibile. Mai degrabă, ei înțeleg greșit proprietățile fundamentale ale codului care trăiește într-o bază de date și rulează într-un mod descentralizat.

Contactarea serviciilor externe

Adesea, primul caz de utilizare propus este un contract inteligent care își schimbă comportamentul ca răspuns la un eveniment extern. De exemplu, o poliță de asigurare agricolă care plătește condiționat în funcție de cantitatea de precipitații dintr-o anumită lună. Procesul imaginat decurge cam așa: contractul inteligent așteaptă până la ora predeterminată, preia raportul meteo de la un serviciu extern și se comportă corespunzător pe baza datelor primite.

Toate acestea sună destul de simplu, dar este și imposibil. De ce? Deoarece un blockchain este un sistem bazat pe consens, ceea ce înseamnă că funcționează numai dacă fiecare nod atinge o stare identică după procesarea fiecărei tranzacții și blocuri. Tot ceea ce are loc pe un blockchain trebuie să fie complet determinist, fără nicio modalitate posibilă de a pătrunde diferențele. În momentul în care două noduri cinstite nu sunt de acord cu privire la starea lanțului, întregul sistem devine lipsit de valoare.

Acum amintiți-vă că contractele inteligente sunt executate independent de fiecare nod dintr-un lanț. Prin urmare, dacă un contract inteligent preia unele informații dintr-o sursă externă, această preluare este efectuată în mod repetat și separat de fiecare nod. Dar pentru că această sursă este în afara blockchain-ului, nu există nicio garanție că fiecare nod va primi același răspuns. Poate că sursa își va schimba răspunsul în timpul dintre solicitările de la diferite noduri sau poate că va deveni temporar indisponibilă. Oricum, consensul este rupt și întregul blockchain moare.

Deci, care este soluția? De fapt, este destul de simplu. În loc ca un contract inteligent să inițieze preluarea datelor externe, una sau mai multe părți de încredere („oracole”) creează o tranzacție care încorporează datele respective în lanț. Fiecare nod va avea o copie identică a acestor date, astfel încât să poată fi utilizat în siguranță într-un calcul de contract inteligent. Cu alte cuvinte, un oracol împinge datele pe blockchain mai degrabă decât un contract inteligent trăgând e in.

Când vine vorba de contractele inteligente care provoacă evenimente în lumea exterioară, apare o problemă similară. De exemplu, multora le place ideea unui contract inteligent care apelează la API-ul unei bănci pentru a transfera bani. Dar dacă fiecare nod execută independent codul din lanț, cine este responsabil pentru apelarea acestui API? Dacă răspunsul este doar un nod, ce se întâmplă dacă acel nod anume funcționează defectuos, deliberat sau nu? Și dacă răspunsul este fiecare nod, putem avea încredere în fiecare nod cu parola acelui API? Și chiar vrem ca API-ul să fie apelat de sute de ori? Și mai rău, dacă contractul inteligent trebuie să știe dacă apelul API a avut succes, ne întoarcem imediat la problema dependenței de datele externe.

Ca și înainte, este disponibilă o soluție simplă. În loc ca contractul inteligent să apeleze un API extern, folosim un serviciu de încredere care monitorizează starea blockchain-ului și efectuează anumite acțiuni ca răspuns. De exemplu, o bancă ar putea urmări în mod proactiv un blockchain și poate efectua transferuri de bani care oglindesc tranzacțiile din lanț. Acest lucru nu prezintă niciun risc pentru consensul blockchain-ului, deoarece lanțul joacă un rol complet pasiv.

Privind aceste două soluții, putem face câteva observații. În primul rând, ambele necesită o entitate de încredere pentru a gestiona interacțiunile dintre blockchain și lumea exterioară. Deși acest lucru este posibil din punct de vedere tehnic, subminează obiectivul unui sistem descentralizat. În al doilea rând, mecanismele utilizate în aceste soluții alternative sunt exemple simple citirea și scrierea unei baze de date. Un oracol care furnizează informații externe este pur și simplu să scrie acele informații în lanț. Și un serviciu care oglindește starea blockchain-ului în lumea reală nu face altceva decât să citească din acel lanț. Cu alte cuvinte, orice interacțiune între un blockchain și lumea exterioară este limitată la operațiuni obișnuite de baze de date. Vom vorbi mai multe despre acest fapt mai târziu.

Aplicarea plăților în lanț

Iată o altă propunere pe care tindem să o auzim foarte des: folosirea unui contract inteligent pentru a automatiza plata cupoanelor pentru așa-numita „obligăție inteligentă”. Ideea este ca codul de contract inteligent să inițieze automat plățile la momentele adecvate, evitând procesele manuale și garantând că emitentul nu poate fi implicit.

Desigur, pentru ca acest lucru să funcționeze, fondurile folosite pentru efectuarea plăților trebuie să trăiască și în interiorul blockchain-ului, altfel un contract inteligent nu ar putea garanta plata acestora. Acum amintiți-vă că un blockchain este doar o bază de date, în acest caz un registru financiar care conține obligațiunile emise și niște numerar. Deci, atunci când vorbim despre plăți cu cupoane, ceea ce vorbim de fapt sunt operațiuni de bază de date care au loc automat la o oră convenită.

Deși această automatizare este fezabilă din punct de vedere tehnic, suferă de o dificultate financiară. Dacă fondurile utilizate pentru plățile cupoanelor sunt controlate de contractul inteligent al obligațiunii, atunci acele plăți pot fi într-adevăr garantate. Dar asta înseamnă și acele fonduri nu poate fi folosit de emitentul de obligațiuni pentru nimic altceva. Și dacă acele fonduri nu sunt sub controlul contractului inteligent, atunci nu există nicio modalitate prin care plata poate fi garantată.

Cu alte cuvinte, o obligațiune inteligentă este fie inutilă pentru emitent, fie inutilă pentru investitor. Și dacă te gândești bine, acesta este un rezultat complet evident. Din perspectiva unui investitor, scopul unei obligațiuni este rata atractivă de rentabilitate, cu prețul unui anumit risc de neplată. Iar pentru emitent, scopul unei obligațiuni este de a strânge fonduri pentru o activitate productivă, dar oarecum riscantă, cum ar fi construirea unei noi fabrici. Nu există nicio modalitate ca emitentul de obligațiuni să folosească fondurile strânse, garantând în același timp că investitorul va fi rambursat. Nu ar trebui să fie o surpriză că legătura dintre risc și rentabilitate nu este o problemă pe care blockchains-ul o poate rezolva.

Ascunderea datelor confidențiale

Așa cum am făcut scris despre anterior, cea mai mare provocare în implementarea blockchain-urilor este transparența radicală pe care acestea o oferă. De exemplu, dacă zece bănci au înființat un blockchain împreună și două efectuează o tranzacție bilaterală, aceasta va fi imediat vizibilă pentru celelalte opt. Deși există diverse strategii pentru atenuarea acestei probleme, niciuna nu depășește simplitatea și eficiența unei baze de date centralizate, în care un administrator de încredere are control deplin asupra cine poate vedea ce.

Unii oameni cred că contractele inteligente pot rezolva această problemă. Ele încep cu faptul că fiecare contract inteligent conține propria sa bază de date în miniatură, asupra căreia are control deplin. Toate operațiunile de citire și scriere din această bază de date sunt mediate de codul contractului, făcând imposibil ca un contract să citească în mod direct datele altuia. (Această cuplare strânsă între date și cod se numește încapsulare și este baza popularității programare orientată obiect paradigmă.)

Deci, dacă un contract inteligent nu poate accesa datele altuia, am rezolvat problema confidențialității blockchain? Are sens să vorbim despre ascunderea informațiilor într-un contract inteligent? Din păcate, răspunsul este nu. Pentru că, chiar dacă un contract inteligent nu poate citi datele altuia, acele date sunt încă stocate pe fiecare nod din lanț. Pentru fiecare participant blockchain, acesta se află în memoria sau discul unui sistem pe care participantul îl controlează complet. Și nimic nu îi împiedică să citească informațiile din propriul sistem, dacă și când aleg să facă acest lucru.

Ascunderea datelor într-un contract inteligent este la fel de sigură ca și ascunderea lor în codul HTML al unei pagini web. Sigur, utilizatorii web obișnuiți nu îl vor vedea, deoarece nu este afișat în fereastra browserului lor. Dar tot ce este nevoie este ca un browser web să adauge o funcție „Vizualizare sursă” (cum au toate acestea), iar informațiile ascunse devin universal vizibile. În mod similar, pentru datele ascunse în contractele inteligente, tot ce este nevoie este ca cineva să-și modifice software-ul blockchain pentru a afișa starea completă a contractului și se pierde orice aparență de secret. Un programator pe jumătate decent ar putea face asta într-o oră și ceva.

Pentru ce sunt contractele inteligente

Cu atât de multe lucruri pe care contractele inteligente nu le pot face, s-ar putea întreba pentru ce sunt de fapt. Dar pentru a răspunde la această întrebare, trebuie să ne întoarcem la fundamentele blockchain-urilor în sine. Pentru a recapitula, un blockchain permite ca o bază de date să fie partajată direct și în siguranță de către entitățile care nu au încredere una în alta, fără a necesita un administrator central. Blockchain-urile permit dezintermedierea datelor, iar acest lucru poate duce la economii semnificative de complexitate și cost.

Orice bază de date este modificată prin „tranzacții”, care conțin un set de modificări ale acelei baze de date care trebuie să reușească sau să eșueze în ansamblu. De exemplu, într-un registru financiar, o plată de la Alice către Bob este reprezentată de o tranzacție care (a) verifică dacă Alice are fonduri suficiente, (b) deduce o cantitate din contul lui Alice și (c) adaugă aceeași cantitate în contul lui Bob. .

Într-o bază de date centralizată obișnuită, aceste tranzacții sunt create de o singură autoritate de încredere. În schimb, într-o bază de date partajată bazată pe blockchain, tranzacțiile pot fi create de oricare dintre utilizatorii acelui blockchain. Și din moment ce acești utilizatori nu au încredere deplină unul în altul, baza de date trebuie să conțină reguli care restricționează tranzacțiile efectuate. De exemplu, într-un registru financiar de tip peer-to-peer, fiecare tranzacție trebuie să păstreze cantitatea totală de fonduri, altfel participanții s-ar putea oferi în mod liber oricât de mulți bani doresc.

Se pot imagina diverse moduri de exprimare a acestor reguli, dar deocamdată există două paradigme dominante, inspirate de Bitcoin și, respectiv, Ethereum. Metoda Bitcoin, pe care am putea-o numi „constrângeri de tranzacție”, evaluează fiecare tranzacție în termeni de: (a) intrările din baza de date șterse de acea tranzacție și (b) intrările create. Într-un registru financiar, regula prevede că cantitatea totală de fonduri din înregistrările șterse trebuie să se potrivească cu totalul din cele create. (Considerăm că modificarea unei intrări existente este echivalentă cu ștergerea acelei intrări și cu crearea uneia noi în locul ei.)

A doua paradigmă, care vine de la Ethereum, sunt contractele inteligente. Aceasta prevede că toate modificările la datele unui contract trebuie să fie efectuate prin codul acestuia. (În contextul bazelor de date tradiționale, ne putem gândi la aceasta ca la un executată procedura stocată.) Pentru a modifica datele unui contract, utilizatorii blockchain trimit cereri de la codul său, care determină dacă și cum să îndeplinească aceste solicitări. Ca în acest exemplu, contractul inteligent pentru un registru financiar îndeplinește aceleași trei sarcini ca administratorul unei baze de date centralizate: verificarea fondurilor suficiente, deducerea dintr-un cont și adăugarea la altul.

Ambele paradigme sunt eficiente și fiecare are avantajele și dezavantajele sale, așa cum am făcut-o eu discutat în profunzime anterior. Pentru a rezuma, constrângerile tranzacțiilor în stil Bitcoin oferă concurență și performanță superioare, în timp ce contractele inteligente în stil Ethereum oferă o flexibilitate mai mare. Deci, pentru a reveni la întrebarea pentru ce sunt contractele inteligente:

Contractele inteligente sunt pentru cazuri de utilizare blockchain care nu pot fi implementate cu constrângeri de tranzacție.

Având în vedere acest criteriu pentru utilizarea contractelor inteligente, încă nu văd un caz de utilizare puternic pentru blockchain-urile autorizate care se califică. Toate aplicațiile blockchain convingătoare pe care le cunosc pot fi implementate cu tranzacții în stil Bitcoin, care pot gestiona permisiunea și stocarea generală a datelor, precum și crearea, transferul, escrow, schimbul și distrugerea de active. Cu toate acestea, noi cazuri de utilizare încă apar și nu aș fi surprins dacă unele do necesită puterea contractelor inteligente. Sau, cel puțin, o extensie a paradigmei Bitcoin.

Oricare ar fi răspunsul, cheia de reținut este că contractele inteligente sunt pur și simplu o metodă de restricționare a tranzacțiilor efectuate într-o bază de date. Acesta este, fără îndoială, un lucru util și este esențial pentru a face acea bază de date sigură pentru partajare. Dar contractele inteligente nu pot face nimic altceva și, cu siguranță, nu pot scăpa de limitele bazei de date în care își au reședința.

Vă rugăm să postați comentarii la LinkedIn.