Në këtë artikull do të shqyrtojmë se çfarë janë smart kontratat, cilat janë llojet e tyre, do të njohim platforma të ndryshme të smart kontratave, karakteristikat e tyre, si dhe do të diskutojmë mbi strukturën e tyre dhe përfitimet që mund të sjellin. Ky material do të jetë shumë i dobishëm për lexuesit që nuk janë mjaft mirë të njohur me temën e smart kontratave, por duan të afrohen me kuptimin e saj.
Kontrata e zakonshme vs. smart kontrata
Para se të thellohemi në detaje, le të shqyrtojmë një shembull të ndryshimeve midis një kontrate të zakonshme, e cila është vendosur në letër, dhe një smart kontrate, e cila është përfaqësuar në formë digjitale.
Si ka funksionuar para se të shfaqen smart kontratat? Imagjinoni një grup njerëzish që dëshirojnë të vendosin disa rregulla dhe kushte për shpërndarjen e vlerave, si dhe një mekanizëm të caktuar për të garantuar përmbushjen e kësaj shpërndarjeje sipas rregullave dhe kushteve të dhëna. Atëherë ata mblidheshin së bashku, përgatisnin një dokument ku shënonin të dhënat e tyre identifikuese, kushtet, vlerat e përfshira, vendosnin datën dhe nënshkruanin. Ky kontratë gjithashtu ishte e verifikuar nga një palë e besueshme, si një noteri. Më pas, këta njerëz shpërndaheshin në direk të ndryshëm me kopjen e tyre në letër të këtij kontrate dhe fillonin të kryenin disa veprime që mund të mos përputheshin me kontratën vetë, që do të thotë se ata bënin një gjë, ndërsa në letër ishte e verifikuar se duhej të bënin diçka krejtësisht tjetër. Dhe si mund të dalin nga kjo situatë? Në fakt, dikush nga pjesëmarrësit e grupit duhet të merte këtë dokument, të merrte disa prova, të shkonte në gjykatë dhe të kërkonte përputhshmërinë midis kontratës dhe veprimeve reale. Mjaft shpesh, arritja e një ekzekutimi të drejtë të kësaj kontrate ka qenë e vështirë, çka çon në pasoja të pakëndshme.
Çfarë mund të themi për smart kontratat? Ato kombinojnë mundësinë e shkruarjes së kushteve të kontratës dhe mekanizmin përkatës të përmbushjes së sasive të sakta. Nëse kushtet janë përcaktuar dhe është nënshkruar transaksioni ose kërkesa përkatëse, atëherë pas pranimit të kësaj kërkese ose transaksioni, nuk është më e mundur të ndryshohet kushti ose të ndikosh në përmbushjen e tij.
Ekziston një validues i vetëm ose një rrjet i tërë, si dhe një bazë të dhënash që ruan të gjitha kontratat smart, të cilat hyjnë në ekzekutim në një rend të rreptë kronologjik. Është gjithashtu e rëndësishme që kjo bazë të dhënash të përmbajë të gjitha kushtet-trigger për ekzekutimin e kontratës smart. Për më tepër, ajo duhet të marrë parasysh atë vlerë, shpërndarja e së cilës përshkruhet në kontratë. Nëse i referohet ndonjë monedhe digjitale, atëherë kjo bazë duhet ta llogarisë atë.
Në terma të tjerë, validuesit e kontratave smart duhet të kenë qasje në të gjitha të dhënat që operon kontrata smart. Për shembull, një bazë e dhënash duhet të përdoret për të llogaritur njëkohësisht monedhat digjitale, bilancet e përdoruesve, transaksionet e përdoruesve dhe markat e kohës. Atëherë në kontratën smart, kushti mund të jetë bilanci i përdoruesit në një monedhë të caktuar, arritja e ndonjë kohe apo realizimi i ndonjë transaksioni, por asgjë më shumë.
Përkufizimi i kontratës smart
Në fakt, vetë terminologjia u shpik nga studiuesi Nick Szabo dhe u përdor për herë të parë në 1994, ndërsa dokumentimi i saj u bë në 1997 në një artikull që përshkruan vetë idenë e kontratave smart.
Kontratat smart nënkuptojnë se ndodh një automatizim i ndarjes së vlerës, i cili mund të varet vetëm nga kushtet e përcaktuara paraprakisht. Në versionin më të thjeshtë, kjo duket si një kontratë me kushte të dhëna saktësisht, e cila nënshkruhet nga palë të caktuara.
Kontratët smart kanë për qëllim minimizimin e besimit ndaj palëve të treta. Ndonjëherë, qendra e marrjes së vendimeve, nga e cila gjithçka varej, eliminohet plotësisht. Për më tepër, për këto kontrata, auditimi është më i thjeshtë. Kjo është një pasojë e disa veçorive të dizajnimit të një sistemi të tillë, por shpeshherë ne kuptojmë nën kontratat smart një ambient të decentralizuar dhe praninë e funksioneve që i lejojnë çdo dështimi të analizojë bazën e të dhënave dhe të kryejë një audit të plotë të ekzekutimit të kontratave. Kështu garanton mbrojtjen nga ndryshimet e të dhënave retroaktive, të cilat do të sillnin ndryshime në ekzekutimin e vetë kontratës. Digitalizimi i shumicës së proceseve gjatë krijimit dhe nisjes së kontratës smart shpesh e thjeshton teknologjinë dhe koston e zbatimit të saj.
Shembulli i thjeshtë — shërbimi Escrow
Le të shqyrtojmë një shembull shumë të thjeshtë. Ai do të ndihmojë në kuptimin e mundësive funksionale të kontratave inteligjente, si dhe do të ofrojë orientimin më të mirë se në cilat raste është e arsyeshme t'i aplikoni ato.
Ajo mund të realizohet gjithashtu duke përdorur Bitcoin, megjithatë, për momentin, Bitcoin akoma është e vështirë ta quash një platformë të plotë për kontratat inteligjente. Pra, kemi një blerës dhe një dyqan në internet. Blerësi dëshiron të blejë një monitor në këtë dyqan. Në rastin më të thjeshtë, blerësi bën dhe dërgon pagesën, ndërsa dyqani në internet e pranon atë, e konfirmon dhe më pas dërgon produktin. Megjithatë, në këtë situatë, ekziston nevoja për shumë besim — blerësi duhet të besojë dyqanin në internet për një shumë të tërë nga çmimi i monitorit. Duke pasur parasysh se dyqani në internet mund të ketë një reputacion të ulët në sytë e blerësit, ekziston rreziku që për ndonjë arsye, pas pranimit të pagesës, dyqani të refuzojë shërbimin dhe të mos dërgojë produktin te blerësi. Prandaj, blerësi pyetet (si dhe dyqani në internet pyetet për këtë), se çfarë mund të përdoret në këtë rast për të minimizuar këto rreziqe dhe për t'i bërë këto transaksione më të sigurta.
Në rastin e Bitcoin-it, mund të ofrohet mundësia që blerësi dhe shitësi të zgjedhin një ndërmjetës të cilin mund ta besojnë të dy. Ka shumë njerëz që merren me zgjidhjen e çështjeve të kontestuara. Dhe pjesëmarrësit tanë mund të zgjedhin një ndërmjetës nga një listë e përbashkët që ata besojnë të dy. Së bashku krijojnë një adresë multisig 2 nga 3, ku ka tre çelësa dhe janë të nevojshme dy nënshkruese nga çelësat për të shpenzuar monedhat nga kjo adresë. Një çelës do të përkasë blerësit, tjetri — dyqanit në internet, dhe i treti — ndërmjetësit. Dhe në këtë adresë multisig, blerësi do të dërgojë shumën e nevojshme për të paguar monitorin. Tani, kur shitësi sheh se paratë janë bllokuar për njëfarë kohe në adresën multisig, e cila varet nga ai, ai mund të dërgojë me guxim monitorin me postë.
Më pas, blerësi merr pakon, inspekton produktin dhe merr një vendim për blerjen përfundimtare. Ai mund të jetë plotësisht i kënaqur me shërbimin e ofruar dhe të firmosë transaksionin me çelësin e tij, ku ai transferon monedhat nga adresa multisig të shitësit, ose mund të jetë i pakënaqur me diçka. Në këtë rast, ai kontakton një ndërmjetës për të përgatitur një transaksion alternativ, i cili do të shpërndajë këto monedha ndryshe.
Le të supozojmë se monitori ka ardhur disi i gërvishtur dhe në paketim nuk kishte kabllin për t'u lidhur me kompjuterin, megjithëse në faqen e internetit të dyqanit online ishte shkruar se kablli duhet të përfshihet në paketim. Atëherë blerësi mbledh provat e nevojshme për të dëshmuar për ndërmjetësin se është mashtruar në këtë situatë: ai bën screenshot-e të faqes, bën një fotografi të faturës nga posta, bëri një fotografi të gërvishtjeve në monitor dhe tregon se vula ishte thyer dhe kablli ishte nxjerrë. Dyqani online nga ana e tij mbledh provat e tij dhe i kalon ndërmjetësit.
Ndërmjetësi është i interesuar që të kënaqë në të njëjtën kohë ndjeshmërinë e blerësit dhe interesat e dyqanit online (dhe më vonë do të kuptohet pse). Ai përgatis një transaksion të tillë, në të cilin monedhat nga adresa multisig do të shpenzohen në një proporcion të caktuar midis blerësit, dyqanit online dhe ndërmjetësit, pasi ai merr një pjesë si shpërblim për punën e tij. Le të supozojmë, 90% e shumës totale do të shkojë te shitësi, 5% te ndërmjetësi dhe 5% si kompensim për blerësin. Ky transaksion ndërmjetësi e firma me çelësin e tij, por ajo nuk mund të aplikohet ende, sepse për këtë kërkohen dy firma, dhe vetëm një është e pranishme. Një të tillë transaksion ai e dërgon si te blerësi ashtu edhe te shitësi. Nëse të paktën një prej tyre do të jetë i kënaqur me këtë variant të shpërndarjes së monedhave, atëherë transaksioni do të nënshkruhet përfundimisht dhe do të përhapet në rrjet. Për ta validuar, mjafton që një nga pjesëmarrësit në marrëveshje të pranojë variantin e ndërmjetësit.
Është e rëndësishme të zgjidhni fillimisht një mediator, në mënyrë që të dy palët t'i besojnë atij. Në këtë rast, ai do të veprojë në mënyrë të pavarur nga interesat e njërit apo tjetrit dhe do të vlerësojë situatën në mënyrë objektive. Nëse mediator nuk ofron një mundësi të tillë për shpërndarjen e monedhave që e kënaq të paktën një pjesëmarrës, atëherë, duke marrë vesh bashkërisht, si blerësi ashtu edhe dyqani online mund të transferojnë monedhat në një adresë të re multisignature, duke vendosur nënshkrimet e tyre. Adresa e re multisignature do të jetë krijuar me një mediator tjetër, i cili ndoshta do të jetë më i kualifikuar në këtë çështje dhe do të ofrojë një mundësi më të mirë.
Shembulli me konviktin dhe frigoriferin
Le të shqyrtojmë një shembull më të komplikuar, i cili tregon mundësitë e kontratës së mençur më qartë.
Supozoni se ka tre djem që sapo janë vendosur në një dhomë në konvikt. Ata përbëjnë një interes të përbashkët për të blerë një frigorifer për dhomën e tyre, të cilin do ta përdorin së bashku. Njëri prej tyre ka ofruar të mbledhë shumën e nevojshme për blerjen e frigoriferit dhe të negociojë me shitësin. Sidoqoftë, ata janë njohur relativisht së fundmi me njëri-tjetrin dhe mes tyre nuk ka mjaft besim. Është e qartë se dy prej tyre rrezikojnë duke i dhënë paratë të tretit. Për më tepër, ata duhet të arrijnë një marrëveshje në lidhje me zgjedhjen e shitësit.
Ata mund të shfrytëzojnë një shërbim escrow, dmth të zgjedhin një mediator që do të kontrollojë ekzekutimin e marrëveshjes dhe do të zgjidhë çështjet e kontestueshme, nëse ndodhin. Atëherë, duke rënë dakord, ata përgatitin një kontratë të mençur dhe e specifikojnë atë në kushte të caktuara.
Kushti i parë është që deri në arritjen e një kohe të caktuar, le të themi brenda një jave, në llogarinë përkatëse të kontratës inteligjente duhet të pranohet tri pagesa nga adresa të caktuara për një shumë të caktuar. Nëse kjo nuk ndodh, kontrata inteligjente ndalon ekzekutimin e saj dhe kthen monedhat për të gjithë pjesëmarrësit. Nëse kushti përmbushet, atëherë caktohen identifikuesit e shitësit dhe ndërmjetësit, si dhe kontrollohet kushte që të gjithë pjesëmarrësit janë dakord me zgjedhjen e shitësit dhe ndërmjetësit. Kur të gjitha kushtet të përmbushen, atëherë fondet do të transferohen në adresat e caktuara. Ky qasja mund të sigurojë pjesëmarrësit nga mashtrimi nga çdo anë dhe përjashton nevojën për besim.
Ne shohim në këtë shembull parimin se kjo mundësi për të caktuar hapat përkatës për ekzekutimin e çdo kushti lejon krijimin e sistemeve të çdo kompleksiteti dhe thellësie të niveleve të thelluara. Për më tepër, fillimisht në kontratën inteligjente mund të përcaktohet kushti i parë, dhe vetëm pas përmbushjes së tij mund të caktohen parametrat për kushtin tjetër. Në fjalë të tjera, formalisht kushti i shkruhet, ndërsa parametrat për të mund të caktohen gjatë punës së tij.
Klasifikimi i kontratave inteligjente
Për klasifikimin mund të caktohen grupe të ndryshme kriteresh. Megjithatë, në këtë moment të zhvillimit të teknologjive, të rëndësishme janë katër prej tyre.
Kontratave inteligjente mund t'u jepet një dallim sipas mjedisit të ekzekutimit, i cili mund të jetë ose të centralizuar ose të decentralizuar. Në rastin e decentralizimit, ne kemi shumë më shumë pavarësi dhe qëndrushmëri në ekzekutimin e kontratave inteligjente.
Ato gjithashtu mund të dallohet sipas procesit të caktimit dhe ekzekutimit të kushteve: ato mund të jenë të programueshme në mënyrë të rastësishme, të kufizuara ose të paracaktuara, pra të tipizuara. Kur në platformën e kontratave inteligjente ekzistojnë vetëm 4 kontrata të caktuara, parametrat për to mund të caktohen në mënyrë të rastësishme. Përkatësisht, caktimi i tyre është shumë më i lehtë: ne zgjedhim kontratën nga lista dhe kalojmë parametrat.
Në mënyrë të iniciimit, ekzistojnë kontrata inteligjente automatike, që do të thotë se ato ekzekutohen automatikisht kur arrihen kushte të caktuara, dhe ka kontrata të tilla në të cilat kushtet janë të përcaktuara, por platforma nuk verifikon automatikisht përmbushjen e tyre, për këtë duhet të iniciohen veçmas.
Përveç kësaj, kontratat inteligjente dallohen sipas nivelit të privatësisë. Ato mund të jenë ose plotësisht të hapura, ose pjesërisht, ose plotësisht konfidenciale. Kjo e fundit do të thotë se vëzhguesit e tretë nuk e shohin kushtet e kontratave inteligjente. Megjithatë, tema e privatësisë është shumë e gjerë dhe është më mirë të shqyrtohet veçmas nga artikulli aktual.
Më poshtë do të ndalemi më në hollësi në tri kriteret e para, për të sjellë më shumë qartësi në kuptimin e temës aktuale.
Kontratate inteligjente sipas mjedisit të ekzekutimit
Sipërfaqe të ekzekutimit dallojmë platforma të centralizuara dhe të decentralizuara të kontratave inteligjente. Në rastin e kontratave digjitale të centralizuara, përdoret një shërbim, ku ekziston vetëm një validues dhe mund të ketë një shërbim rezervimi dhe rikuperimi, i cili gjithashtu menaxhohet në mënyrë centralizuese. Ekziston një bazë të dhënash që ruan të gjithë informacionin e nevojshëm për të vendosur kushtet e kontratës inteligjente dhe për të shpërndarë vlerën që merret parasysh në këtë bazë të dhënash të shërbimit. Një shërbim të tillë centralizues ka një klient, i cili përmes kërkesave të caktuara vendos kushtet dhe përdor këto kontrata. Për shkak se platforma është centralizuar, mekanizmat e autentikimit mund të jenë më pak të besueshëm se në kriptovaluta.
Si një shembull mund të marrim ofruesit e shërbimeve celulare (operatorë të ndryshëm celular). Supozoni se një operator i caktuar mbajti një regjistrim të trafikut në serverët e tij në mënyrë centralizuese, i cili mund të transmetohet në formate të ndryshme, për shembull: si thirrje vokale, dërgimi i SMS-ve, trafiku i internetit celular dhe sipas standardeve të ndryshme, si dhe mban regjistrimin e fondeve në bilancet e përdoruesve. Për pasojë, ofruesi i shërbimeve celulare mund të krijojë kontrata për regjistrimin e shërbimeve të ofruara dhe pagesat me kushte të ndryshme. Në këtë rast, kushtet lehtë mund të përcaktohen si ‘dërgo një SMS me një kod të caktuar në një numër të caktuar dhe do të marrësh kushte të tilla për shpërndarjen e trafikut’.
Një shembull tjetër mund të përmendet: bankat tradicionale me funksionalitete të zgjeruara të bankarisë në internet dhe kontratat shumë të thjeshta, si pagesat periodike, konvertimi automatik i pagesave që vijnë, dhe përjashtimi automatik i përqindjes në llogarinë e caktuar, etj.
Nëse flasim për kontratat e zgjuara në një mjedis të decentralizuar ekzekutimi, atëherë kemi një grup validuesish. Në rastin ideal, çdo njeri mund të bëhet validues. Nëpërmjet protokollit të sinkronizimit të bazës së të dhënave dhe arritjes së konsensusit, kemi një bazë të përbashkët të të dhënave që do të ruajë tanimë të gjitha transaksionet me kontrata të rrepta të përshkruara, e jo disa kërkesa të kushtezuara, formati i të cilave shpesh ndryshon, dhe nuk ka specifikim të hapur. Këtu transaksionet do të përmbajnë udhëzime për zbatimin e kontratës në përputhje me specifikimin e rreptë. Kjo specifikim është e hapur dhe, si pasojë, përdoruesit e platformës mund të kryejnë auditimin dhe të validuara kontratat e zgjuara. Këtu shohim se platformat decentralizuara kalojnë ato qendrore në pavarësi dhe qëndrueshmëri, por projektimi dhe mirëmbajtja e tyre janë shumë më të komplikuara.
Kontratave të zgjuara sipas mënyrës së caktimit dhe zbatimit të kushteve
Tani do të shqyrtojmë më në detaje se si kontratat e zgjuara mund të ndryshojnë sipas mënyrës së caktimit dhe zbatimit të kushteve. Këtu do të fokusohemi te kontratat e zgjuara që programohen në mënyrë arbitrare dhe janë të plota sipas Turingut. Një kontratë e plotë sipas Turingut lejon caktimin e pothuajse çdo algoritmi si kushte për zbatimin e kontratës: përfshirjen e cikleve, funksioneve të llogaritjes së probabilitetit dhe gjëra të ngjashme - deri në algoritmet e veta të nënshkrimit elektronik. Në këtë rast, ka të bëjë me një shkruese të vërtetë të logjikës.
Po ashtu, dallohen kontratat e zgjuara arbitrare, por jo të plota sipas Turingut. Këtu përfshihen Bitcoin dhe Litecoin me skriptin e tyre. Ka të bëjë me faktin se mund të përdoren në një rend të rastësishëm vetëm disa operacione të caktuara, por nuk mund të shkruhen cikle dhe algoritme të veta.
Përveç kësaj, ekzistojnë platforma të kontratave inteligjente që implementojnë kontrata të paracaktuar. Ndër to janë Bitshares dhe Steemit. Bitshares ka një gamë të gjerë kontratash inteligjente për tregtim, menaxhim llogarish, menaxhim të platformës vetë dhe parametrave të saj. Steemit është një platformë e ngjashme, por ajo nuk është fokusuar në lëshimin e tokenëve dhe tregtinë si Bitshares, por në mbajtjen e blogeve, dmth ajo ruan dhe proceson përmbajtje në mënyrë të decentralizuar.
Për kontratat e plota Turing që janë të rastësishme, mund të përfshijmë platformën Ethereum dhe RootStock, e cila është ende në fazën e zhvillimit. Prandaj, më poshtë do të ndalemi pak më shumë mbi platformën e kontratave inteligjente Ethereum.
Kontratate inteligjente sipas mënyrës së iniciimit
Sipas mënyrës së iniciimit, kontratat inteligjente gjithashtu mund të ndahen në të paktën dy grupe: të automatizuara dhe manuale (të paautomatizuara). Për ato të automatizuara, karakteristikë është që, me të gjitha parametrat e njohur dhe kushtet e arritura, kontrata inteligjente përfundon automatikisht, dmth nuk kërkon dërgimin e ndonjë transaksioni të mëtejshëm dhe shpenzimin e ndonjë tarife shtesë për çdo ekzekutim të ardhshëm. Platforma vetë ka të gjitha të dhënat për të llogaritur se si do të përfundojë kontrata inteligjente. Logjika atje nuk është rastësore, por e paracaktuar dhe gjithçka është parashikueshme. Pra, është e mundur të vlerësohet paraprakisht vështirësia e ekzekutimit të kontratës inteligjente, të përdoret një tarifë konstante për të dhe të gjithë proceset për ekzekutimin e saj kalojnë në një mënyrë më efikase.
Për kontratat inteligjente që programohen në mënyrë të rastësishme, ekzekutimi nuk është automatizuar. Për të iniciuar një kontratë të tillë inteligjente, në fakt në çdo hap duhet të krijohet një transaksion i ri, i cili do të thërrasë fazën tjetër të ekzekutimit ose metodën tjetër të kontratës inteligjente, të pagohet tarifa përkatëse dhe të pritet konfirmimi i transaksionit. Ekzekutimi mund të përfundojë me sukses ose jo, sepse kodi i kontratës inteligjente është rastësor dhe mund të shfaqen disa momente të paparashikueshme, si një cikël përgjithmonë, mungesa e disa parametrave dhe argumenteve, përjashtime të papërpunuara, etj.
Llogaritë në Ethereum
Llojet e llogarive në Ethereum
Të shqyrtojmë cilat mund të jenë llogaritë në platformën Ethereum. Këtu ekzistojnë vetëm dy lloje llogarish dhe asnjë variant tjetër nuk ka. Lloji i parë quhet llogari përdoruesi, ndërsa i dyti është llogaria kontraktuale. Le të kuptojmë se çfarë ndryshimi ka mes tyre.
Llogaria e përdoruesit menaxhohet vetëm me çelësin e tij privat të nënshkrimit. Pronari i llogarisë gjeneron çiftin e tij të çelsave për nënshkrim nëpërmjet algoritmit ECDSA (Elliptic Curve Digital Signature Algorithm). Vetëm transaksionet e nënshkruara me këtë çelës mund të ndryshojnë gjendjen e kësaj llogarie.
Për llogarinë e smart kontraktit është parashikuar një logjikë e veçantë. Ajo mund të menaxhohet vetëm përmes një kodi programimi të caktuar paraprakisht, i cili përcakton plotësisht sjelljen e smart kontraktit: si do të menaxhojë monedhat e tij në rrethana të caktuara, nga iniciativa e cilit përdorues dhe gjatë cilave kushte shtesë do të shpërndahen këto monedha. Nëse disa aspekte nuk parashikohen nga zhvilluesit në kodin programues, mund të lindin probleme. Për shembull, smart kontrakti mund të arrijë një gjendje të caktuar, në të cilën ai nuk pranon të inicojë vazhdimin e mëtejshëm nga asnjë nga përdoruesit. Në këtë rast, monedhat do të mbeten të ngrira, sepse smart kontrakti nuk parashikon një mënyrë për të dalë nga kjo gjendje.
Si krijohen llogaritë në Ethereum
Në rastin e llogarisë së përdoruesit, pronari gjeneron vetë çiftin e çelsave përmes ECDSA. Është e rëndësishme të theksohet se Ethereum përdor të njëjtin algoritëm për nënshkrimin elektronik dhe të njëjtën kurbë eliptike si Bitcoin, por adresa llogaritet ndryshe. Këtu nuk aplikohet rezultati i dyfishtë i heshimit, siç ndodh në Bitcoin, por parashikohet një heshim i vetëme me funksionin Keccak me gjatësi 256 bit. Nga vlera e marrë, priten bitët më të ulët, duke përfshirë 160 bitët më të ulët të vlerës së daljes nga funksioni hash. Si rezultat, ne marrim adresën në Ethereum. Në fakt, ajo zë 20 byte.
Vlen të theksohet se identifikuesi i llogarisë në Ethereum kodifikohet në hex pa përdorimin e kontrollit të shumës, ndryshe nga Bitcoin dhe shumë sisteme të tjera, ku adresa kodifikohet në sistemin e numërimit me bazën 58 me shtimin e kontrollit të shumës. Kjo do të thotë se duhet të punohet me identifikuesit e llogarive në Ethereum me kujdes: madje një gabim i vetëm në identifikues do të rezultojë duke humbur monedhat.
Ka një veçori të rëndësishme dhe ajo është se llogaria e përdoruesit në nivelin e bazës së të dhënave krijohet në momentin kur ai pranon pagesën e parë të ardhshme.
Përsa i përket krijimit të llogarive të kontratave inteligjente, aplikohet një qasje krejtësisht ndryshe. Fillimisht, një nga përdoruesit shkruan kodin burimor të kontratës inteligjente, pas së cilës kodi kalon përmes një kompilatori të veçantë për platformën Ethereum, duke marrë kodin e byte për makinerinë virtuale Ethereum. Kodi i marrë ngarkohet në një fushë të veçantë të transaksionit. Ajo firmoset në emër të llogarisë iniciatore. Më pas, kjo transaksion shpërndahet në rrjet dhe vendos kodin e kontratës inteligjente. Komisioni për realizimin e transaksionit dhe, për rrjedhojë, për ekzekutimin e kontratës, merret nga bilanci i llogarisë iniciatore.
Çdo kontratë inteligjente përmban patjetër ndërtuesin e saj (të kësaj kontrate). Ai mund të jetë bosh, ose mund të ketë përmbajtje. Pasi ndërtuesi ekzekutohet, krijohet një identifikues llogarie për kontratën inteligjente, duke përdorur të cilin mund të dërgoni monedha, të thërrisni metoda të caktuara të kontratës inteligjente etj.
Struktura e transaksionit Ethereum
Për t'u qartësuar, ne do të fillojmë me shqyrtimin e strukturës së transaksionit Ethereum dhe një shembull të kodit të kontratës inteligjente.
Transaksioni Ethereum përbëhet nga disa fusha. Fusha e parë është nonce — ky është një numër rendor i transaksionit në lidhje me llogarinë vet që e shpërndan dhe është autori i saj. Kjo është e nevojshme për të dalluar dyfishimet e transaksioneve, për të përjashtuar rastin kur një transaksion i njëjtë pranohet dy herë. Falë përdorimit të identifikuesit, çdo transaksion ka një vlerë hash unike.
Më pas vjen një fushë e tillë si çmimi i gazitKëtu tregohet çmimi me të cilin valuta bazë Ethereum konvertohet në gas, i cili paguan për ekzekutimin e kontratës inteligjente dhe ndarjen e burimeve të makinerisë virtuale. Çfarë do të thotë kjo?
Në Bitcoin, provigjionet paguhen direkt në monedhën bazë — vetë bitcoinin. Kjo është e mundur falë një mekanizmi të thjeshtë llogaritjeje: ne paguajmë saktësisht sipërfaqen e të dhënave që janë të pranishme në transaksion. Në Ethereum situata është më komplekse, sepse është shumë e vështirë të bazohet në volumet e të dhënave. Këtu transaksioni gjithashtu mund të përmbajë kod programues që do të ekzekutohet në makineritë virtuale, dhe çdo operacion i makinës virtuale mund të ketë një kompleksitet të ndryshëm. Ka gjithashtu operacione që rezervojnë memorie për variablat. Ato do të kenë kompleksitetin e vet, mbi të cilin do të varet pagesa për çdo operacion.
Kostoja e çdo operacioni në ekuivalentin e gas-it do të jetë konstante. Kjo është vendosur pikërisht për të përcaktuar koston konstante për çdo operacion. Sipas ngarkesës në rrjet, çmimi i gas-it do të ndryshojë, pra faktorët sipas të cilëve valuta bazë do të konvertohet në këtë njësi ndihmëse për pagesën e provigjioneve.
Ka një veçori tjetër të transaksioneve në Ethereum: kodi i bajtëve që ajo përmban për ekzekutim në makinën virtuale do të ekzekutohet deri sa të përfundojë me një rezultat të caktuar (sukses-dështim) ose derisa të mbarojnë disa monedha të rezervuara për pagimin e provigjionit. Në mënyrë që të shmangen situatat kur llogaria e dërguesit në rast ndonjë gabimi shpenzon të gjitha monedhat për provigjon (për shembull, nëse një cikël i pafund ka filluar në makinën virtuale), ekziston ky fushë e mëposhtme — start gas (e njohur shpesh si gas limit) — e cila përcakton sasinë maksimale të monedhave që dërguesi është i gatshëm të shpenzojë për ekzekutimin e një transaksioni të caktuar.
Fusha tjetër quhet destination address. Këtu shkruhet adresa e marrësit të monedhave ose adresa e një kontrate inteligjente specifike, metodat e të cilave do të thirren. Pas saj vijon fusha vlera, ku shkruhet shuma e monedhave që dërgohen në destination address.
Më pas ndodhet një fushë interesante e quajtur data, ku përfshihet një strukturë e tërë. Kjo nuk është një fushë e veçantë, por një strukturë e tërë, në të cilën përcaktohet kodi për makinën virtuale. Këtu mund të vendosen të dhëna të rastësishme — për këtë ekzistojnë rregulla të veçanta.
Dhe fusha e fundit quhet nënshkrim. Ajo përmban njëkohësisht si nënshkrimin elektronik të autorit të kësaj transaksioni, ashtu edhe çelësin publik, me të cilin do të kontrollohet ky nënshkrim. Nga çelësi publik mund të merret identifikuesi i llogarisë së dërguesit të kësaj transaksioni, pra identifikon njëherë e përgjithmonë llogarinë e dërguesit në sistemin vetë. Në lidhje me strukturën e transaksionit, ne zbuluam thelbin.
Shembulli i kodit të kontratës së mençur në Solidity
Tani le të shqyrtojmë më në detaje kontratën më të thjeshtë të mençur në shembuj.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Më lart është paraqitur kodi i thjeshtuar, i cili mund të mbajë monedhat e përdoruesve dhe t'i kthejë ato sipas kërkesës.
Pra, ekziston kontrata e mençur Bank, e cila kryen funksione të mëposhtme: ajo akumulon monedha në bilancin e saj, pra kur konfirmohet transaksioni dhe vendoset një kontratë e tillë, krijohet një llogari e re, e cila mund të përmbajë monedha në bilancin e saj; ajo mban mend përdoruesit dhe shpërndarjen e monedhave ndërmjet tyre; ka disa metoda për menaxhimin e bilancit, pra ekziston mundësia e mbushjes, tërheqjes dhe kontrollit të bilancit të përdoruesit.
Le të kalojmë nëpër çdo rresht të kodit burimor. Në këtë kontratë ka fusha konstante. Njëra prej tyre, me tipin address, quhet owner. Këtu kontrata mban mend adresën e përdoruesit që krijoi këtë kontratë të mençur. Më pas, ka një strukturë dinamike, e cila ruan përputhjet ndërmjet adresave të përdoruesve dhe bilanceve.
Pas kësaj vjen metoda Bank — ajo quhet ashtu si kontrata. Prandaj, ky është konstruktor i saj. Këtu ndodh caktimi i ndryshores owner me adresën e atij që vendosi këtë kontratë të mençur në rrjet. Kjo është e vetmja gjë që ndodh në këtë konstruktor. Pra, msg në këtë rast është pikërisht ato të dhëna që i janë dërguar makinës virtuale së bashku me transaksionin, i cili përmban të gjithë kodin e kësaj kontrate. Prandaj, msg.sender është autori i këtij transaksioni, i cili vendos këtë kod. Ai do të jetë pronari i kontratës së mençur.
Metoda deposit lejon të transferojë një sasi të caktuar monedhash në llogarinë e kontratës përmes një transaksioni. Në këtë rast, kontrata smart, duke marrë këto monedha, i ruan ato në bilancin e saj, por në strukturën e balances regjistron se kush ishte dërguesi i këtyre monedhave, në mënyrë që të di se për kë i takojnë.
Metoda tjetër quhet withdraw dhe ajo pranon një parametrin — shumën e monedhave që dikush dëshiron të tërheqë nga ky bankë. Këtu bëhet një kontroll nëse mjaft monedha ka në bilancin e përdoruesit që thërret këtë metodë për t'i dërguar ato. Nëse ka mjaftueshëm, atëherë kontrata smart kthen shumën e kërkuar për thirrësin.
Më pas, vijon metoda për kontrollimin e bilancit aktual të përdoruesit. Ai që thërret këtë metodë do të përdoret për të marrë këtë bilanc në kontratën smart. Duhet të theksohet se modifikatori i kësaj metode është view. Kjo do të thotë se vetë metoda nuk ndryshon asnjë variabël të klasës së saj dhe në fakt është vetëm një metodë leximi. Një transaksion i veçantë nuk krijohet për thirrjen e kësaj metode, komisioni nuk paguhet, dhe të gjitha llogaritjet kryhen lokal, pas së cilës përdoruesi merr rezultatin.
Metoda kill është e nevojshme për të shkatërruar gjendjen e kontratës smart. Dhe këtu është një kontroll shtesë, nëse ai që thërret këtë metodë është pronari i kësaj kontrate. Nëse është, atëherë kontrata vetë-shkatërrohet, dhe funksioni i shkatërrimit merr një parametrin — identifikuesin e llogarisë në të cilën kontrata do të dërgojë të gjitha monedhat e mbetura në bilanc. Në këtë rast, monedhat e mbetura automatikisht do të shkojnë në adresën e pronarit të kontratës.
Si funksionon një nod i plotë në rrjetin Ethereum?
Le të shohim në mënyrë skematike se si ndodh ekzekutimi i këtyre kontratave smart në platformën Ethereum dhe si funksionon një nod i plotë në rrjet.
Një nod i plotë në rrjetin Ethereum duhet të ketë të paktën katër module.
E para, si për çdo protokoll të decentralizuar, është moduli i rrjetit P2P — moduli i lidhjeve të rrjetit dhe punës me nodet e tjera, ku ndodh shkëmbimi i blloqeve, transaksioneve, informacionit mbi nodet e tjera. Ky është një komponent tradicional për të gjitha kriptovalutat e decentralizuara.
Pastaj, kemi një modul për ruajtjen e të dhënave të blockchain, përpunimin, zgjedhjen e degës prioritare, shtimin e blloqeve, shkëputjen e blloqeve, verifikimin e këtyre blloqeve etj.
Moduli i tretë quhet EVM (Ethereum virtual machine) — kjo është makina virtuale, e cila merr kodin byte nga transaksioni Ethereum. Ky modul pranon gjendjen aktuale të një llogarie të caktuar dhe bën ndryshimet në gjendjen e saj mbi bazën e kodit byte të marrë. Versioni i makinës virtuale në çdo nyje të rrjetit duhet të jetë i njëjtë. Llogaritjet ndodhin në çdo nyje të Ethereum krejtësisht njësoj, por ndodhin në një rend të asinkronizuar: dikush verifikon dhe pranon këtë transaksion më herët, domethënë ekzekuton të gjithë kodin e përfshirë në të, ndërsa dikush më vonë. Ndryshe, kur krijohet një transaksion, ai shpërndahet në rrjet, nyjet e pranimit dhe në momentin e verifikimit ashtu si në Bitcoin ekzekutohet Bitcoin Script, këtu ekzekutohet kodi byte i makinës virtuale.
Një transaksion konsiderohet i verifikuar nëse i gjithë kodi i përfshirë në të është ekzekutuar, është krijuar një gjendje e re e një llogarie të caktuar dhe është ruajtur deri sa të kuptohet nëse ky transaksion është aplikuar apo jo. Nëse transaksioni është aplikuar, atëherë kjo gjendje konsiderohet jo vetëm e realizuar, por edhe aktuale. Ekziston një bazë të dhënash që ruan gjendjen e çdo llogarie për çdo nyje të rrjetit. Falë faktit që të gjitha llogaritjet ndodhin njësoj dhe gjendja e blockchain është e njëjtë, atëherë bazat e të dhënave që përmbajnë gjendjet e gjitha llogarive gjithashtu do të jenë të njëjta për çdo nyje.
Mitet dhe kufizimet e kontratave të mençura
Sa i përket kufizimeve që ekzistojnë për platformat e ngjashme me Ethereum për kontratat e mençura, mund të përmendim si më poshtë:
- ekzekutimi i kodit;
- alokimi i memories;
- të dhënat e blockchain;
- dërgimi i pagesave;
- krijimi i kontratave të reja;
- thirrja e kontratave të tjera.
Le të shqyrtojmë ato kufizime që vendosen mbi makinën virtuale dhe, për rrjedhojë, t'i heqim dyshimet për kontratat dhe sistemet e mençura. Makinën virtuale, e cila mund të jetë jo vetëm në Ethereum, por edhe në platforma të ngjashme, mund të kryejnë operacione logjike të vërteta, dmth mund të shkruajmë kod dhe ai do të ekzekutohet atje, gjithashtu është e mundur të marrësh më shumë kujtesë. Megjithatë, tarifa paguhet veç e veç për çdo operacion dhe për çdo njësi shtesë kujtesë të alokuar.
Më tej, makinat virtuale mund të lexojnë të dhëna nga baza e të dhënave të blockchain, në mënyrë që të përdorin këto të dhëna si një shkak për ekzekutimin e logjikës së caktuar të kontratave të mençura. Makinat virtuale mund të krijojnë dhe dërgojnë transaksione, ato mund të krijojnë kontrata të reja dhe të thërrasin metoda të kontratave të tjera të mençura, të cilat tashmë janë publikuar në rrjet: ekzistojnë, janë të arritshme, etj.
Miti më i zakonshëm është se kontratat dhe sistemet e mençura të Ethereum mund të përdorin informacione nga çdo burim të internetit në kushtet e tyre. E vërteta është se makina virtuale nuk mund të dërgojë ndonjë kërkesë rrjeti në një burim të jashtëm informacioni në internet, dmth nuk mund të shkruhet një kontratë e tillë inteligjente që do të shpërndajnë vlerën midis përdoruesve në varësi të asaj, për shembull, se çfarë moti ka jashtë, ose se kush fitoi në ndonjë kampionat, ose mbi bazën e ndonjë ngjarjeje tjetër që ndodhi në botën e jashtme, sepse informacione për këto ngjarje thjesht nuk ekzistojnë në bazën e të dhënave të platformës vetë. Domethënë, nuk ka asgjë mbi këtë në blockchain. Nëse nuk shfaqet atje, as makina virtuale nuk mund të përdorë këto të dhëna si shkak.
Disavantazhet e Ethereum
Le të rendisim disa nga to. Dobësia e parë është se ekzistojnë disa vështirësi në projektimin, zhvillimin dhe testimin e kontratave të mençura në Ethereum (për të shkruar kontrata të mençura në Ethereum përdoret gjuha Solidity). Në të vërtetë, praktika tregon se një përqindje shumë e madhe e të gjitha gabimeve i përket faktorëve njerëzorë. Kjo është e vërtetë edhe për kontratat e mençura të shkruara tashmë në Ethereum, të cilat kanë kompleksitet të mesëm ose më të lartë. Nëse për kontratat e mençura të thjeshta probabiliteti i gabimit është i vogël, në kontratat e mençura të komplikuara shpesh hasen gabime që çojnë në vjedhjen e fondeve, në ngrirjen e tyre, në shkatërrimin e kontratave të mençura në mënyrë të paparashikuar, etj. Janë të njohura shumë raste të tilla.
Dobësia e dytë është se vetë makina virtuale nuk është perfekte, pasi ajo gjithashtu është e shkruar nga njerëz. Ajo mund të ekzekutojë komanda të rastësishme dhe këtu qëndron shkaku i një cenueshmërie: disa komanda mund të konfigurohen në një mënyrë që do të çojnë në pasoja të paparashikuara. Kjo është një fushë shumë komplekse, por tashmë ekzistojnë disa hulumtime që tregojnë se këto cenueshmëri janë në versionin aktual të rrjetit Ethereum dhe ato mund të çojnë në dështimin e funksionimit të shumë kontratave të mençura.
Një vështirësi tjetër e madhe, e cila mund të konsiderohet si një dobësi. Ajo përbëhet nga fakti se në një mënyrë praktike ose teknike mund të arrihet në përfundimin se nëse kompilohet kodi binar i kontratës, e cila do të ekzekutohet në makinën virtuale, mund të përcaktohet një renditje specifike e operacioneve. Kur ekzekutohen së bashku, këto operacione ngarkojnë shumë makinën virtuale dhe ngadalësojnë atë pa proporcion me tarifën që është paguar për ekzekutimin e këtyre operacioneve.
Në të kaluarën, ka pasur një periudhë të tillë zhvillimi për Ethereum, kur shumë persona që kishin njohuri të thella mbi funksionimin e makinerisë virtuale gjetën vulnerabilitete të tilla. Në fakt, transaksionet paguanin një tarifë shumë të vogël, por ngadalësuan ndjeshëm funksionimin e tërë rrjetit. Zgjidhja e këtyre problemeve është shumë e ndërlikuar, sepse e para, ato duhet të determinohen, e dyta, të korigjohet çmimi për realizimin e këtyre operacioneve, dhe e treta, të kryhet një hard fork, e cila do të thotë përditësimi i të gjitha nyjave të rrjetit në një version të ri të softuerit, dhe më pas aktivizimi i këtyre ndryshimeve në mënyrë të njëkohshme.
Sa i përket Ethereum, janë kryer shumë hulumtime, është marrë përvojë shumë të madhe praktike: si pozitive ashtu edhe negative, por megjithatë mbeten sfida dhe vulnerabilitete, me të cilat duhet të përballohemi.
Pra, pjesa tematike e artikullit ka përfunduar, le të kalojmë në pyetje që shfaqen mjaft shpesh.
Pyetje të shpeshta
— Nëse të gjitha palët e kontratës së mençur dëshirojnë të ndryshojnë kushtet, a mund të anulojnë këtë kontratë të mençur përmes një shumëfirmaje, dhe pastaj të krijojnë një kontratë të re me kushtet e përditësuara të realizimit?
Këtu përgjigjia do të jetë dyfish. Pse? Sepse në njërën anë kontrata e mençur përcaktohet njëherë dhe nuk nënkupton ndonjë ndryshim, ndërsa nga ana tjetër, ajo mund të ketë një logjikë të paracaktuar, e cila parashikon ndryshimin e plotë ose të pjesshëm të disa kushteve. Kështu që, nëse dëshironi të ndërroni diçka në kontratën tuaj të mençur, atëherë duhet ta parashikoni paraprakisht kushdinë në të cilat mund të përditësoni këto kushte. Prandaj, vetëm në këtë mënyrë të kujdesshme mund të organizoni përditësimin e kontratës. Por edhe këtu mund të bini në telashe: të bëni një gabim dhe të merrni një vulnerabilitet të përkatshëm. Prandaj, këto gjëra duhet të projektohen dhe testohen me shumë kujdes.
— Dhe nëse një ndërmjetës bashkohet me një nga palët pjesëmarrëse: escrow ose kontratën e mençur? A është e domosdoshme ndërmjetësi në kontratën e mençur?
Mediatori nuk është i detyrueshëm në kontratën smart. Ai mund të mos jetë prezent. Nëse në rastin e escrow, mediatori bie në marrëveshje me njërën nga palët, atëherë, po, ky skemë humbet menjëherë të gjithë vlerën e saj. Prandaj, mediatorët zgjidhen në atë mënyrë që të besohen nga të gjitha palët e përfshira në këtë proces. Përkatësisht, ju thjesht nuk do të transferoni monedha në adresën me shumë firma me atë mediator, të cilit nuk i besoni.
— A është e mundur që me një transaksion Ethereum të transferoni shumë token-e të ndryshme nga adresa juaj në adresa të ndryshme, për shembull, adresat e tregut ku tregtohen këto token-e?
Ky është një pyetje e mirë dhe ai lidhet me modelin e transaksioneve Ethereum dhe dallimin e tij nga modeli Bitcoin. Dhe ndryshimi është thelbësor. Në modelin e transaksionit Ethereum, ju thjesht transferoni monedha, të cilat transferohen vetëm nga një adresë në një tjetër, pa kthim, thjesht një sasi specifike që ju keni caktuar. Me fjalë të tjera, kjo nuk është një model i shpenzimeve të pa përdorura (UTXO), por një model i llogarive dhe balancave përkatëse. Teorikisht, është e mundur të dërgoni shumë token-e të ndryshme me një transaksion, nëse shkruani një smart contract të mençur, por prapëseprapë do të duhej të bënit shumë transaksione, të krijonit kontraktin, pastaj t'i jepnit atij token-a dhe monedha, dhe pastaj të thërrisnit metodën përkatëse. Kjo kërkon përpjekje dhe kohë, përkatësisht, në praktikë kjo nuk funksionon ashtu dhe të gjitha pagesat në Ethereum bëhen me transaksione të veçanta.
— Një nga mite mbi platformën Ethereum është se është e pamundur të përshkruhen kushte që do të varen nga të dhënat e një burimi të jashtëm në internet, si duhet të veprohet atëherë?
Zgjidhja është se vetë smart contract mund të parashikojë një ose disa orakuj të besuar, të cilët mbledhin të dhëna mbi gjendjen e gjërave në botën e jashtme dhe i dërgojnë ato në smart contracts përmes metodash të veçanta. Vete kontrata e beson si të vërteta ato të dhëna që merr nga palët e besuara. Për më shumë besueshmëri, thjesht zgjidhet një grup më i madh orakujsh dhe minimizohet rreziku i marrëveshjeve mes tyre. Vetë kontrata mund të mos marrë parasysh të dhëna nga orakujt që bien ndesh me shumicën.
Kësaj teme i kushtohet një nga ligjëratat e kursit online mbi Blockchain — “”.
Burimi: habr.com
