Në këtë artikull, do të shqyrtojmë se çfarë janë kontratat inteligjente, cilat janë llojet e tyre, do të njohim platformat e ndryshme të kontratave inteligjente, karakteristikat e tyre, si dhe do të diskutojmë për mënyrën se si funksionojnë dhe cilat përfitime mund të ofrojnë. Ky materiale do të jetë shumë i dobishëm për lexuesit që nuk janë mjaft të njohur me temën e kontratave inteligjente, por dëshirojnë të afrohen me kuptimin e saj.
Kontrata e zakonshme vs. kontrata inteligjente
Para se të zhytim thellë në detaje, le të shqyrtojmë me një shembull ndryshimet midis një kontrate të zakonshme, e cila formulohet në letër, dhe një kontrate inteligjente, e cila paraqitet në formë digjitale.
Si si ndodhte para se të shfaqeshin kontratat inteligjente? Imagjinoni një grup njerëzish që duan të vendosin disa rregulla dhe kushte për shpërndarjen e vlerave dhe gjithashtu një mekanizëm të caktuar për të garantuar përmbushjen e kësaj shpërndarjeje sipas rregullave dhe kushteve të përcaktuara. Atëherë ata mblidheshin së bashku, përgatitnin një dokument ku regjistronin të dhënat e tyre identifikuese, kushtet, vlerat e përfshira, vendosnin datën dhe nënshkruheshin. Këtë kontratë gjithashtu e vërtetonte një palë e besueshme, si për shembull një noter. Më pas, këta njerëz shpërndaheshin në drejtime të ndryshme me versionin e tyre të shkruar të kësaj kontrate dhe fillonin të kryenin disa veprime që mund të mos përputheshin me kontratën e vet, pra bënin një gjë, ndërsa në letër ishte e vulosur se duhet të bënin një tjetër. Si të dilte nga kjo situatë? Në thelb, njëri prej anëtarëve të grupit duhet të marrë këtë dokument, të marrë disa prova, të shkojë në gjykatë dhe të kërkojë përputhshmërinë mes kontratës dhe veprimeve faktike. Shpesh, të arrihet një përmbushje e drejtë e kësaj kontrate është e vështirë, gjë që çon në pasoja të pakëndshme.
Çfarë mund të thuhet për kontratat smart? Ato bashkojnë mundësinë për të shkruar kushtet e marrëveshjes dhe mekanizmin e zbatimit të rreptë të tyre. Nëse kushtet janë përcaktuar dhe është nënshkruar transaksioni ose kërkesa përkatëse, atëherë pasi të pranohet kjo kërkesë ose transaksion, nuk është më e mundur të ndryshohen kushtet ose të ndikohen në zbatimin e tyre.
Ka një validues ose një e tërë rrjet, si dhe një bazë të dhënash që ruan të gjitha kontratat smart, të cilat janë pranuar për zbatim në një rend të rreptë kronologjik. Një tjetër gjë e rëndësishme është që kjo bazë të dhënash duhet të përmbajë të gjithë kushtet-trigger për zbatimin 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 kjo ka të bëjë me një monedhë dixhitale, atëherë kjo bazë të dhënash duhet ta marrë parasysh atë.
Me thënë ndryshe, validuesit e kontratave inteligjente duhet të kenë akses në të gjithë të dhënat me të cilat operon kontrata inteligjente. Për shembull, një bazë të dhënash duhet të përdoret për të regjistruar në mënyrë të njëkohshme monedhat dixhitale, balancet e përdoruesve, transaksionet e përdoruesve dhe etiketat e kohës. Atëherë, një kusht në kontratën inteligjente mund të jetë balanca e përdoruesit në një monedhë të caktuar, arritja e një momenti të caktuar, ose një fakt i realizimit të një transaksioni të caktuar, por jo më shumë se kaq.
Definimi i kontratës inteligjente
Në përgjithësi, terminologjia vetë u shpik nga hulumtuesi Nick Szabo dhe u aplikua për herë të parë në vitin 1994, e dokumentuar më pas në vitin 1997 në një artikull që përshkruan idenë e kontratave inteligjente.
Kontratatë inteligjente nënkuptojnë se ekziston një automatizim i caktuar i shpërndarjes së vlerës, i cili mund të varet vetëm nga ato kushte që janë paracaktuar më parë. Në variantin më të thjeshtë, kjo duket si një kontratë me kushte strikte të caktuara, e cila është nënshkruar nga palë të caktuara.
Kontratet smart janë krijuar për të minimizuar besimin në palët e treta. N sometimes, qendra e vendimmarrjes është plotësisht e përjashtuar, duke bërë që gjithçka të varet nga sistemi i decentralizuar. Për më tepër, është më e lehtë të kryhet një audit për këto kontrata. Kjo është një pasojë e disa veçorive të dizajnit të këtij sistemi, por më shpesh ne e kuptojmë kontratin smart si një mjedis të decentralizuar me funksione që lejojnë çdo të interesuar të analizojë bazën e të dhënave dhe të kryejë një audit të plotë të zbatimit të kontratave. Kështu sigurohet mbrojtja nga ndryshimi i të dhënave në mënyrë retrospektive, të cilat do të çonin në ndryshime në zbatimin e vetë kontratës. Digjitalizimi i shumicës së proceseve gjatë krijimit dhe zbatimit të kontratave smart shpesh e thjeshton teknologjinë dhe kostot e realizimit të tyre.
Një shembull i thjeshtë — shërbimi Escrow
Le të shqyrtojmë një shembull shumë të thjeshtë. Ai do të ndihmojë në afrim me kuptimin e mundësive funksionale të kontratave smart, si dhe të orientoheni më mirë në rastet kur vlen t'i aplikohet ato.
Kjo mund të realizohet gjithashtu me përdorimin e Bitcoin-it, megjithëse tani Bitcoin-i është ende e vështirë ta quajmë një platformë të plotë për kontratat inteligjente. Pra, kemi një blerës dhe një dyqan online. Blerësi dëshiron të blejë një monitor në këtë dyqan. Në mënyrën më të thjeshtë, blerësi kryen dhe dërgon pagesën, dhe dyqani online e pranon atë, e konfirmon, pas së cilës dërgon produktin. Megjithatë, në këtë situatë, ekziston një nevojë e madhe për besim — blerësi duhet t'i besojë dyqanit online tërë vlerën e monitorit. Pasi dyqani online mund të ketë një reputacion të ulët në sytë e blerësit, ekziston rreziku që për ndonjë arsye pas pranim pagesës, dyqani të refuzojë shërbimin dhe të mos dërgojë produktin te blerësi. Prandaj, blerësi ngre pyetjen (po ashtu, dhe dyqani online e ngre këtë pyetje), çfarë mund të aplikojmë në këtë rast për të minimizuar këto rreziqe dhe për të bërë që këto transaksione të jenë më të sigurta.
Në rastin e Bitcoin-it, mund të ofrohet mundësia që blerësi dhe shitësi të zgjedhin ndarësin e tyre të verifikimit. Ekzistojnë shumë persona që merren me zgjidhjen e mosmarrëveshjeve. Dhe pjesëmarrësit tanë mund të zgjedhin nga një listë të përgjithshme të ndarësve, atë që të dyja palët do të besojnë. Së bashku, ata krijojnë një adresë multisig 2 nga 3, ku ka tre çelësa dhe nevojiten dy nënshkrime nga çfarëdo dy çelësa për të shpenzuar monedhat nga kjo adresë. Një çelës do t’i përkasë blerësit, i dyti do t’i përkasë dyqanit online, ndërsa i treti do t’i përkasë ndarësit. Dhe në këtë adresë multisig, blerësi do të dërgojë shumën e nevojshme për pagesën e monitorit. Tani, kur shitësi sheh se paratë janë bllokuar për një kohë të caktuar në adresën multisig, e cila varet prej tij, ai mund të dërgojë me guxim monitorin me postë.
Më pas, blerësi merr paketën, inspekton mallin 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ë nënshkruajë transaksionin me çelësin e tij, ku transferon monedha nga adresa multisignature te shitësi, ose mund të ketë disa pakënaqësi. Në këtë rast, ai kontakon ndërmjetësin për të përgatitur një transaksion alternativ, i cili do të shpërndajë këto monedha ndryshe.
Supozoni se monitori erdhi disi i gërvishtur dhe në paketim nuk kishte kabllin për lidhjen me kompjuterin, megjithëse në faqen e internetit të dyqanit online ishte shkruar se kablli duhej të përfshihej. Atëherë blerësi grumbullon provat e nevojshme për të provuar ndërmjetësit se është mashtruar në këtë situatë: ai bën screenshot-e të faqes, bën një fotografi të faturës nga posta, fotografon gërvishtjet në monitor dhe tregon se vula është thyer dhe kablli është nxjerrë. Dyqani online nga ana e tij grumbullon provat e veta dhe ia dërgon ndërmjetësit.
Mediatori është i interesuar të kënaqë njëkohësisht si pakënaqësinë e blerësit ashtu edhe interesat e internet-marketit (më vonë do të shpjegohet pse). Ai krijon një transaksion në të cilin monedhat nga adresa multisignature do të shpenzohen në një përqindje të caktuar mes blerësit, internet-marketit dhe mediatorit, pasi ai merr një pjesë si shpërblim për punën e tij. Le të themi se 90% e gjithë shumës do të shkojë te shitësi, 5% te mediatori dhe 5% si kompensim për blerësin. Ky transaksion mediatori e nënshkruan me çelësin e tij, por ende nuk mund të zbatohet, sepse për këtë nevojiten dy nënshkrime, kurse aktualisht ka vetëm një. Ai dërgon një transaksion si te blerësi ashtu edhe te shitësi. Nëse të paktën njëri prej tyre është i kënaqur me këtë mundësi të rishpërndarjes së monedhave, atëherë transaksioni do të nënshkruhet dhe do të shpërndahet në rrjet. Për ta validuar mjafton që një nga pjesëmarrësit e marrëveshjes të pranojë opsionin e mediatorit.
Është e rëndësishme që fillimisht të zgjidhni 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 ndonjërit dhe do të vlerësojë situatën në mënyrë objektive. Nëse mediatorja nuk ofron një mundësi ndarjeje të monedhave që e kënaqin të paktën një nga pjesëmarrësit, atëherë, duke u marrë vesh së bashku, si blerësi ashtu edhe dyqani online mund të transferojnë monedhat në një adresë të re multisignature, duke vendosur dy nënshkrimet e tyre. Adresa e re multisignature do të përbëhet tashmë me një mediator tjetër, i cili ndoshta do të jetë më kompetent mbi çështjen dhe do të ofrojë një mundësi më të mirë.
Shembulli me konvikte dhe frigoriferin
Le të shqyrtojmë një shembull më të komplikuar, i cili pasqyron mundësitë e kontratës inteligjente më qartë.
Supozoni se, që janë tre djem që sapo janë vendosur në një dhomë në një konvikt. Ata janë të gjithë të interesuar të blejnë një frigorifer për dhomën e tyre, të cilin do ta përdorin së bashku. Njëri prej tyre ofroi të mbledhë shumën e nevojshme për blerjen e frigoriferit dhe të negocijojë me shitësin. Megjithatë, ata janë njohur për një kohë të shkurtër dhe nuk ka ndonjë besim të mjaftueshëm midis tyre. Është e dukshme se dy prej tyre rrezikojnë, duke i dhënë para njërit. Për më tepër, ata duhet të arrijnë një marrëveshje për zgjedhjen e shitësit.
Ata mund të përdorin një shërbim escrow, që do të thotë të zgjedhin një ndërmjetës që do të kontrollojë ekzekutimin e transaksionit dhe të zgjidhë çdo mosmarrëveshje nëse të tilla lindin. Atëherë, pasi bien dakord, ata përgatisin një kontratë inteligjente dhe e shkruajnë në të kushtet e caktuara.
Kushti i parë është që deri në një kohë të caktuar, le të themi brenda një jave, në llogarinë përkatëse të kontratës së mençur duhet të mbërrijnë tre pagesa nga adresat e caktuara për një shumë të caktuar. Nëse kjo nuk ndodh, kontrata e mençur ndalon përmbushjen e saj dhe iu kthen monedhat të gjithë pjesëmarrësve. Nëse kushti përmbushet, atëherë vendosen vlerat e identifikuesve të shitësit dhe ndërmjetësit, si dhe kontrollohet kushti që të gjithë pjesëmarrësit bien dakord me zgjedhjen e shitësit dhe ndërmjetësit. Kur të gjitha kushtet të përmbushen, në vazhdim mjetet do të transferohen në adresat e caktuara. Ky qasje mund të mbrojë pjesëmarrësit nga mashtrimi nga çfarëdo palë dhe në përgjithësi përjashton nevojën për të besuar.
Ne këtë shembull shohim parimin që mundësia për të vendosur hap pas hapi parametrat për realizimin e çdo kushti lejon krijimin e sistemeve të çdo komplekset dhe thellësie të niveleve të ndërlidhura. Për më tepër, fillimisht në kontratën e mençur mund të përcaktohet kushti i parë, dhe vetëm pas përmbushjes së tij mund të vendosen parametrat për kushtin tjetër. Në fjalë të tjera, formalisht kushti shkruhet, ndërsa parametrat për të mund të vendosen gjatë funksionimit të tij.
Klasifikimi i kontratave të mençura
Për klasifikimin mund të përcaktohen grupe të ndryshme kriteresh. Sidoqoftë, në këtë moment të zhvillimit të teknologjive, e rëndësishme janë katër prej tyre.
Kontratave të mençura mund t'uivim sipas mjedisit të ekzekutimit, i cili mund të jetë ose i centralizuar, ose i decentralizuar. Në rastin e decentralizimit, kemi një pavarësi shumë më të madhe dhe qëndrueshmëri për gjatë realizimit të kontratave të mençura.
Ata mund të dallohen gjithashtu sipas procesit të caktimit dhe realizimit të kushteve: ato mund të jenë programueshmë sipas dëshirës, të kufizuara ose të paracaktuar, pra, të tipizuara me saktësi. Kur në platformën e kontratave inteligjente ekzistojnë vetëm 4 kontrata të caktuara, parametrat për to mund të caktosen në mënyrë të rastësishme. Prandaj, caktimi i tyre është shumë më i lehtë: ne zgjedhim kontratën nga lista dhe kalojmë parametrat.
Sipas mënyrës së iniciimit, ekzistojnë kontrata inteligjente automatizuar, që do të thotë se kur ndodhin kushte të caktuara ato realizohen automatikisht, dhe ka kontrata në të cilat kushtet janë të caktuara, por platforma nuk verifikon automatikisht realizimin e tyre, për këtë ato duhet të iniciohen veçmas.
Përveç kësaj, kontratat inteligjente ndryshojnë sipas nivelit të privatësisë. Ato mund të jenë ose plotësisht të hapura, ose pjesërisht, ose plotësisht konfidenciale. E fundit do të thotë se vëzhguesit e jashtëm nuk e shohin kushtet e kontratave inteligjente. Megjithatë, tema e privatësisë është shumë e gjerë dhe është më mirë të shqyrtohet ndaras nga ky artikull.
Më poshtë do të ndalemi më në detaje mbi tre kriteret e para, për të sjellë më shumë qartësi në kuptimin e temës aktuale.
Kontratave të mençura sipas mjedisit të ekzekutimit
Sipas mjedisit të ekzekutimit, dallohen platformat e centralizuara dhe të decentralizuara të kontratave të mençura. Në rastin e kontratave dixhitale të centralizuara, përdoret një shërbim i vetëm, ku ekziston vetëm një validues dhe mund të ketë një shërbim rezervë dhe rikuperimi, i cili menaxhohet gjithashtu në mënyrë centralizuese. Ekziston një bazë e dhënash që ruan të gjitha informacionet e nevojshme për përcaktimin e kushteve të kontratës së mençur dhe shpërndarjen e asaj vlere që llogaritet në këtë bazë të dhënash të shërbimit. Ky shërbim centralizues ka një klient, i cili me kërkesa të caktuara përcakton kushte dhe përfiton nga këto kontrata. Për shkak se platforma është centralizuese, mekanizmat e autentifikimit mund të jenë më pak të besueshëm se në criptovaluta.
Si një shembull mund të marrim ofruesit e shërbimeve mobile (operatorët e ndryshëm mobil). Të themi, një operator i caktuar mban një regjistrim të centralizuar të trafikut në serverat e tij, i cili mund të transmetohet në formate të ndryshme, për shembull: në formën e thirrjeve zanore, dërgimit të SMS-ve, trafikut të internetit mobil dhe sipas standardeve të ndryshme, dhe gjithashtu mbajti një regjistrim të fondeve në bilancet e përdoruesve. Si pasojë, ofruesi i shërbimeve mobile mund të krijojë kontrata për regjistrimin e shërbimeve të ofruara dhe pagesat e tyre me kushte të ndryshme. Në një rast të tillë, lehtësisht mund të përcaktohen kushte 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."
Mund të japim edhe një shembull tjetër: bankat tradicionale me funksionalitete të zgjeruara të bankës në internet dhe kontratat shumë të thjeshta si pagesat e rregullta, konvertimi automatik i pagesave të ardhshme, dhe ndarja automatike e përqindjes në një llogari të caktuar etj.
Kur bëhet fjalë për kontratat smart me një mjedis të decentralizuar ekzekutimi, atëherë kemi një grup validuesish. Në rastin ideal, kushdo mund të bëhet validues. Falë protokollit të sinkronizimit të bazës së të dhënave dhe arritjes së konsensusit, ne kemi një bazë të përbashkët të të dhënave, e cila do të ruajë tani të gjitha transaksionet me kontrata të përshkruara në mënyrë strikte, e jo disa kërkesa të kushtëzuara, formati i të cilave shpesh ndryshon dhe nuk ka një specifikim të hapur. Këtu, transaksionet do të përmbajnë udhëzime për ekzekutimin e kontratës në përputhje me specifikimin e rreptë. Kjo specifikim është e hapur dhe, si rezultat, përdoruesit e vetë platformës mund të kryejnë audite dhe të validojnë kontratat smart. Këtu shohim se platformat e decentralizuara tejkalojnë ato të centralizuara në pavarësi dhe qëndrueshmëri kundrejt dështimit, por projektimi dhe mbajtja e tyre janë shumë më komplekse.
Kontratatat smart sipas mënyrës së caktimit dhe ekzekutimit të kushteve
Tani analizojmë më në detaje se si kontratat smart mund të ndryshojnë sipas mënyrës së caktimit dhe ekzekutimit të kushteve. Këtu do të përqendrohemi te kontratat smart që programohen në mënyrë të rastësishme dhe janë të plota sipas Turingut. Një kontratë smart e plotë sipas Turingut lejon caktimin e praktikisht çdo algoritmi si kushte për ekzekutimin e kontratës: përfshirje e cikleve, disa funksione për llogaritjen e probabiliteteve dhe ashtu me radhë — deri te algoritmet tuaja të nënshkrimit elektronik. Në këtë rast, flasim për shkruarjen e logjikës në mënyrë të vërtetë të rastësishme.
Po ashtu, dallohet kontratat smart të rastësishme, por jo të plota sipas Turingut. Këtu përfshihet Bitcoin dhe Litecoin me skriptin e tyre. Këtu kuptohet se mund të përdorim operacione të caktuara në rend të rastësishëm, por nuk është e mundur të shkruajmë cikle dhe algoritme të veta.
Përveç kësaj, ekzistojnë platforma të smart kontratave që realizojnë smart kontrata të parapara. Ndër to përfshihet Bitshares dhe Steemit. Bitshares ka një gamë të gjerë smart kontratash për tregti, menaxhimin e llogarive, menaxhimin e platformës dhe parametrave të saj. Steemit është një platformë e ngjashme, por ajo fokusohet jo në lëshimin e tokenëve dhe tregti, si Bitshares, por në blogim, domethënë ruan dhe përpunon përmbajtje në mënyrë të decentralizuar.
Këto kontrata të plota Turing të rastësishme përfshijnë platformën Ethereum dhe RootStock, e cila është ende në fazën e zhvillimit. Prandaj, më poshtë do të ndalemi pak më shumë te platforma e smart kontratave Ethereum.
Smart kontratat sipas mënyrës së iniciatës
Nëpërmjet metodës së iniciimit, kontratat inteligente gjithashtu mund të ndahen në minimum në dy grupe: të automatizuara dhe manuale (jo automatizuara). Për ato automatizuar është karakteristikë që, për të gjitha parametrat e njohur dhe kushtet e ndodhura, kontrata intelligente ekzekutohet plotësisht automatikisht, domethënë nuk kërkon dërgimin e ndonjë transaksioni të shtuar dhe shpenzimin e një komisioni shtesë për çdo ekzekutim të mëtejshëm. Platforma vetë ka të dhëna të mjaftueshme për të llogaritur se si do të përfundojë kontrata intelligente. Logjika atje nuk është arbitrale, por e përcaktuar më parë dhe gjithçka është parashikueshme. Domethënë, paraprakisht mund të vlerësohet kompleksiteti i ekzekutimit të kontratës inteligente, të përdoret një komision konstant për të dhe të gjitha proceset e ekzekutimit të saj kalojnë në një mënyrë më efikase.
Për kontratat smart që programohen në mënyrë të rastësishme, realizimi nuk është i automatizuar. Për të iniciuar një kontratë të tillë, në çdo hap është e nevojshme të krijohet një transaksion i ri që do të aktivizojë fazën tjetër të realizimit ose metodën tjetër të kontratës smart, të paguhet tarifa përkatëse dhe të pritet konfirmimi i transaksionit. Zgjedhja mund të përfundojë me sukses ose jo, sepse kodi i kontratës smart është i rastësishëm dhe mund të shfaqen disa momente të paparashikueshme, si cikli i përhershëm, mungesa e disa parametrave dhe argumenteve, përjashtime të papërpunuara, etj.
Llogaritë në Ethereum
Llojet e llogarive në Ethereum
Të shohim se cilat mund të jenë llogaritë në platformën Ethereum. Këtu ekzistojnë vetëm dy lloje llogarish dhe asnjë variant tjetër. Lloji i parë quhet llogari përdoruesi, ndërsa i dyti — llogari kontrakte. Të kuptojmë se çfarë i ndan ato.
Llogaria e përdoruesit menaxhohet vetëm nga çelësi personal i nënshkrimit. Pronari i llogarisë gjeneron çiftin e vet të çelësave për nënshkrimin elektronik sipas algoritmit ECDSA (Algoritmi i Nënshkrimit Digjital të Kurrizit Eliptik). Vetëm transaksionet e nënshkruara me këtë çelës mund të ndryshojnë gjendjen e kësaj llogarie.
Për llogarinë e kontratës smart ekziston një logjikë e veçantë. Ajo mund të menaxhohet vetëm me anë të kodit të programuar paraprakisht, i cili përcakton plotësisht sjelljen e kontratës smart: si do të disponojë monedhat e saj në rrethana të caktuara, nga cili përdorues do të hisen dhe nën cilat kushte shtesë do të shpërndahen ato monedha. Nëse disa aspekte nuk parashikohen nga zhvilluesit në kodin e programit, mund të lindin probleme. Për shembull, kontrata smart mund të arrijë një gjendje të caktuar, ku nuk pranon fillimin e kryerjes së mëtejshme nga asnjë nga përdoruesit. Në këtë rast, monedhat faktikisht do të ngeleshin të bllokuara, sepse kontrata smart nuk parashikon një dalje nga kjo gjendje.
Si krijohen llogaritë në Ethereum
Në rastin e llogarisë së përdoruesit, pronari krijon vetë një çift çelësash me ECDSA. Është e rëndësishme të theksohet se Ethereum përdor të njëjtin algoritëm dhe të njëjtën kurbë eliptike për nënshkrimin elektronik si Bitcoin, por adresa llogaritet disi ndryshe. Këtu nuk aplikohet rezultati i dyfishim hashing, si në Bitcoin, por parashikohet vetëm një hash me funksionin Keccak me gjatësi 256 biti. Nga vlera e marrë, priten bitët e poshtëm, pra 160 bitët më të poshtëm të daljes së funksionit 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ërdorur checksum, ndryshe nga Bitcoin dhe shumë sisteme të tjera, ku adresa kodifikohet në sistemin e numërimit me bazë 58 me shtimin e checksum-it. Kjo do të thotë se duhet të punoni me identifikues të llogarive në Ethereum me kujdes: madje një gabim në identifikues do të sjellë me siguri humbjen e monedhave.
Ka një veçori të rëndësishme, e cila përfshin se llogaria e përdoruesit në nivelin e bazës së të dhënave krijohet në momentin kur ai/pranimi i parë të një pagese që vjen.
Për krijimin e llogarisë së kontratës së mençur përdoret një qasje krejtësisht tjetër. Fillimisht, ndonjë nga përdoruesit shkruan kodin burimor të kontratës së mençur, pas së cilës kodi kalon përmes një kompilatori të veçantë për platformën Ethereum, duke marrë kodin në bajt për makinë virtuale Ethereum. Kodi në bajt e marrë vendoset në një fushë të veçantë transaksioni. Ajo nënshkruhet në emër të llogarisë nismëtare. Më pas, kjo transaksion shpërndahet në rrjet dhe vendos kodin e kontratës së mençur. Krahu për kryerjen e transaksionit dhe, për pasojë, për zbatimin e kontratës, merret nga bilanci i llogarisë nismëtare.
Çdo kontratë e mençur patjetër përmban konstruktorin e saj (të kësaj kontrate). Ai mund të jetë bosh, por gjithashtu mund të ketë përmbajtje. Pas ekzekutimit të konstruktorit, krijohet një identifikues llogarie për kontratën e mençur, duke përdorur të cilin, mund të dërgoni monedha, të thërrisni metoda të caktuara të kontratës së mençur, etj.
Struktura e transaksionit Ethereum
Për ta bërë më të qartë, do të fillojmë shqyrtimin e strukturës së transaksionit Ethereum dhe një shembulli të kodit të kontratës inteligjente.
Transaksioni Ethereum përbëhet nga disa fusha. E para është nonce — një numër rendor transaksioni në lidhje me vetë llogarinë që e shpërndan dhe është autori i saj. Kjo është e nevojshme për të dalluar dyfishimet e transaksioneve, duke përjashtuar rastin kur një transaksion i njëjtë pranohet dy herë. Falë përdorimit të identifikuesit, çdo transaksion ka një vlerë unike hash.
Pas kësaj vjen një fushë tjetër, e cila është gas price. Këtu tregohet çmimi me të cilin monedha bazë Ethereum konvertohet në gas, i cili paguhet për ekzekutimin e kontratës inteligjente dhe alokimin e burimeve të makinerisë virtuale. Çfarë do të thotë kjo?
Në Bitcoin, tarifat paguhen në mënyrë direkte me monedhën baze — vetë Bitcoin-in. Kjo është e mundur përmes një mekanizmi të thjeshtë llogaritjeje: ne paguajmë saktësisht për vëllimin e të dhënave që ndodhen në transaksion. Në Ethereum, situata është më e komplikuar, sepse është shumë e vështirë të përcaktosh vëllimin e të dhënave në transaksion. Këtu, transaksioni gjithashtu mund të përmbajë kod programi që do të ekzekutohet në makinat virtuale, dhe çdo operacion në makinat virtuale mund të ketë kompleksitete të ndryshme. Ka gjithashtu operacione që alokojnë memorie për variablat. Këto do të kenë kompleksitetin e tyre, nga i cili do të varet pagesa për çdo operacion.
Kostoja e çdo operacioni në ekuivalentin e gas-it do të jetë konstante. Ajo është futur posaçërisht për të përcaktuar koston konstante të çdo operacioni. Në varësi të ngarkesës në rrjet, do të ndryshojë çmimi i gas-it, që do të thotë koeficienti me të cilin monedha baze do të konvertohet në këtë njësinë ndihmëse përPagesën e tarifës.
Ka një veçori tjetër të transaksionit në Ethereum: kodi i bajtave që përmban për të ekzekutuar në makinën virtuale do të ekzekutohet deri në momentin kur të përfundojë me një rezultat të caktuar (sukses-dështim) ose derisa të përfundojë një sasi e caktuar monedhash, e cila është ndarë për pagesën e taksës. Pikërisht për të shmangur situatën kur nga llogaria e dërguesit, në rast ndonjë gabimi, shpenzohen të gjitha monedhat për taksë (p.sh., ndonjë cikël i pafund është nisur në makinën virtuale), ekziston fusha e mëposhtme — start gas (e cila shpesh quhet kufiri i gazit) — 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 smart specifike, metodat e së cilës do të thirren. Pas saj vjen fusha vlera, ku shkruhet sasia e monedhave që dërgohen në destination address.
Më pas ndodhet një fushë interesante me emrin data, ku është një strukturë e plotë. Kjo nuk është një fushë e veçantë, por një strukturë e tërë, ku përcaktohet kodi për makinë virtuale. Mund të futen informacione të rastësishme këtu — 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ë verifikohet ky nënshkrim. Nga çelësi publik mund të marresh identifikuesin e llogarisë së dërguesit të kësaj transaksioni, domethënë identifikimin unik të llogarisë së dërguesit në sistemin e vet. Nga struktura e transaksionit, ne e sqaruam esencialen.
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 përmes shembujve.
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ë sipër është paraqitur kodi i thjeshtuar burimor, i cili mund të mbajë monedhat e përdoruesve dhe t'i kthejë ato për kërkesë.
Pra ndaj, kemi një kontratë të mençur Bank, e cila kryen funksione të ndryshme: ajo grumbullon monedha në bilancin e saj, domethënë, me miratimin e transaksionit dhe vendosjen e një kontrate të 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 midis tyre; ka disa metoda për menaxhimin e bilancit, domethënë, ekziston mundësia e depozitimit, tërheqjes dhe verifikimit të bilancit të përdoruesit.
Le të shqyrtojmë çdo rresht të kodit burimor. Në këtë kontratë ka fusha konstante. Njëri prej tyre, me tipin adresë, quhet owner. Këtu kontrata mban mend adresën e përdoruesit që krijoi këtë kontratë të mençur. Më pas, ekziston një strukturë dinamike, e cila ruan përputhjet midis adresave të përdoruesve dhe bilancit.
Pas kësaj, vjen metoda Bank - e cila ka emrin e njëjtë si kontrata. Kështu, ky është ndërtuesi i saj. Këtu ndodh caktimi i variablës owner me adresën e atij që ka publikur këtë smart kontratë në rrjet. Kjo është e vetmja gjë që ndodh në këtë ndërtues. Pra, msg në këtë rast janë pikërisht të dhënat që u dërguan makinës virtuale së bashku me transaksionin që përmban të gjithë kodin e kësaj kontrate. Kështu, msg.sender është autori i këtij transaksioni, i cili publikoi këtë kod. Ai do të jetë pronari i smart kontratës.
Metoda deposit lejon dërgimin me një transaksion të një sasi të caktuar monedhash në llogarinë e kontratës. Në këtë rast, smart kontrata, duke marrë këto monedha, i ruan ato në bilancin e saj, por në strukturën balances regjistron se kush ishte dërguesi i këtyre monedhave, për ta ditur se kujt i përkasin ato.
Metoda e mëposhtme quhet withdraw dhe pranon një parametër — shumën e monedhave që dikush dëshiron të tërheqë nga ky bank. Këtu bëhet një kontroll nëse ka mjaft monedha në bilancin e përdoruesit që e thërret këtë metodë për t'i dërguar ato. Nëse ka mjaft, atëherë smart kontrakti kthen këtë sasi monedhash tek thirrësi.
Më pas vjen metoda për kontrollimin e bilancit aktual të përdoruesit. Ajo që e thërret këtë metodë do të përdoret për të marrë këtë bilanc në smart kontrakt. Vlen të theksohet se modifikatori i kësaj metode është — view. Kjo do të thotë se metoda vetë 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, nuk paguhet asnjë tarifë dhe të gjitha llogaritjet kryhen në mënyrë lokale, pas së cilës përdoruesi merr rezultatin.
Metoda kill është e nevojshme për të shkatërruar gjendjen e smart kontratës. Këtu ka një kontroll shtesë, nëse ai që thërret këtë metodë është pronari i kësaj kontrate. Nëse po, atëherë kontrata shkaterrohet dhe funksioni i shkatërrimit merr një parametër — identifikuesin e llogarisë, në të cilin kontrata do të dërgojë të gjitha monedhat e mbetura në bilancin e saj. Në këtë rast, monedhat e mbetura do të shkojnë automatikisht në adresën e pronarit të kontratës.
Si funksionon nodi i plotë i rrjetit Ethereum?
Le të shqyrtojmë skematike se si ndodh ekzekutimi i këtyre smart kontratave në platformën Ethereum dhe si funksionon nodi i plotë i rrjetit.
Nodi i plotë i rrjetit Ethereum duhet të ketë së paku katër module.
I pari, ashtu si për çdo protokoll të decentralizuar, është moduli i rrjetit P2P — moduli për lidhjen dhe punën me nodet e tjera, ku ndodhet shkëmbimi i blloqeve, transaksioneve, dhe informacionit mbi nodet e tjera. Ky është një komponent tradicional për të gjitha kriptovalutat e decentralizuara.
Pastaj, ne kemi një modul për ruajtjen e të dhënave të blockchain-it, përpunimin, zgjedhjen e degës prioritar, shtimin e bllokëve, shkëputjen e bllokëve, verifikimin e këtyre bllokëve, etj.
Moduli i tretë quhet EVM (Etherum Virtual Machine) — kjo është makinë virtuale, e cila pranon kodin në bajta nga transaksioni i Ethereum. Ky modul merr gjendjen aktuale të një llogarie të caktuar dhe kryen ndryshime në gjendjen e saj mbi bazën e kodit të marrë në bajta. Versioni i makinerisë virtuale në çdo nyje të rrjetit duhet të jetë i njëjtë. Llogaritjet ndodhin në çdo nyje të Ethereum-t krejt të njëjta, por ndodhin në mënyrë asinkrone: dikush e verifikon dhe pranon këtë transaksion më herët, pra ekzekuton të gjithë kodin që përmban, ndërsa dikush tjetër më vonë. Prandaj, kur krijohet një transaksion, ai shpërndahet në rrjet, nyjet e pranojnë atë dhe në momentin e verifikimit gjithashtu, ashtu si në Bitcoin ekzekutohet Bitcoin Script, këtu ekzekutohet kodi në bajta i makinerisë virtuale.
Transaksioni konsiderohet i verifikuar nëse gjithë kodi që përmban është ekzekutuar, një gjendje e re e një llogarie të caktuar është gjeneruar dhe ruajtur deri sa të bëhet e qartë nëse ky transaksion është aplikuar apo jo. Nëse transaksioni aplikohet, atëherë kjo gjendje konsiderohet jo vetëm e përfunduar, por gjithashtu e vlefshme. Ekziston një bazë të dhënash që ruan gjendjen e çdo llogarie për çdo nyje të rrjetit. Duke qenë se të gjitha llogaritjet kryhen njësoj dhe gjendja e bllokut është e njëjtë, ashtu edhe baza e të dhënave që përmban gjendjet e të gjitha llogarive do të jetë e njëjtë për çdo nyje.
Mitet dhe kufizimet e kontratave inteligjente
Sa i përket kufizimeve që ekzistojnë për platformat e ngjashme me Ethereum të kontratave inteligjente, mund të përmenden këto:
- ekzekutimi i kodit;
- ndarja e kujtesës;
- të dhënat e bllokut;
- dërgimi i pagesave;
- krijimi i një kontrate të re;
- thirrja e kontratave të tjera.
Le të shqyrtojmë kufizimet që i janë vendosur makinerisë virtuale dhe, për rrjedhojë, të hedhim poshtë disa mite mbi kontratat inteligjente. Në makinerinë virtuale, e cila mund të jetë jo vetëm në Ethereum, por edhe në platforma të ngjashme, është e mundur të kryhen operacione logjike vërtet të rastësishme, dmth, të shkruhet kod dhe ai do të ekzekutohet atje, gjithashtu mund të ndahen nga memorie shtesë. Megjithatë, komisioni paguhet veçmas për çdo operacion dhe për çdo njësi shtesë të hapësirës së memories së ndara.
Më tej, makina virtuale mund të lexojë të dhëna nga baza e të dhënave të blockchain-it, për të përdorur këto të dhëna si një nxitës për ekzekutimin e logjikës së caktuara të kontratave inteligjente. Makina virtuale mund të krijojë dhe dërgojë transaksione, mund të krijojë kontrata të reja dhe të thërrasë metoda të kontratave të tjera inteligjente që tashmë janë publikuar në rrjet: ekzistojnë, janë të aksesueshme, etj.
Miti më i zakonshëm është se kontratat e mençura Ethereum mund të përdorin informacione nga çdo burim në internet në kushtet e tyre. E vërteta është se makineri virtuale nuk mund të dërgojë kërkesa në internet në ndonjë burim informativ të jashtëm, pra nuk është e mundur të shkruhet një kontratë e tillë që do të shpërndante vlerën mes përdoruesve në varësi të, për shembull, kush është moti jashtë, ose kush fitoi në ndonjë kampionat, ose në bazë të ndonjë ngjarjeje tjetër që ndodhi në botën jashtë, sepse informacioni për këto ngjarje thjesht nuk ekziston në bazën e të dhënave të platformës vetë. Në blockchain nuk ka asgjë në lidhje me këtë. Nëse nuk ka atje, atëherë makineri virtuale nuk mund ta përdorë këtë informacion si triggers.
Disavantazhet e Ethereum
Le të përmendim disa nga ato. Dobësia e parë është se ka disa vështirësi në projektimin, zhvillimin dhe testimin e kontratave inteligjente në Ethereum (në Ethereum, gjuha Solidity përdoret për të shkruar kontratat inteligjente). 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ë gjithashtu e vlefshme për kontratat inteligjente të shkruara më parë në Ethereum, të cilat kanë një kompleksitet mesatar ose më të lartë. Nëse për kontratat inteligjente të thjeshta probabiliteti i gabimeve është i ulët, në kontratat inteligjente të komplikuara shpesh hasen gabime që çojnë në vjedhjen e fondeve, në ngrirjen e tyre, në shkatërrimin e kontratave inteligjente në mënyra të papritur etj. Ka pasur shumë raste të tilla të njohura.
Dobësia e dytë është se vetë makina virtuale nuk është perfekte, pasi është gjithashtu e shkruar nga njerëzit. Ajo mund të ekzekutojë komanda të rastësishme dhe këtu qëndron një dobësi: është e mundur të konfigurohen në një mënyrë të caktuar disa komanda që do të çonin në pasoja të paparashikuara. Kjo është një fushë shumë komplekse, por tashmë ekzistojnë disa studime që tregojnë se këto dobësi janë në versionin aktual të rrjetit Ethereum dhe ato mund të çojnë në dështimin e shumë kontratave inteligjente.
Një tjetër vështirësi e madhe, që mund të konsiderohet si një dobësi. Kjo qëndron në faktin se mund të arrish në përfundimin se, nëse kompilohet kodi i bajtit të kontratës që do të ekzekutohet në makinën virtuale, është e mundur të përcaktohet një rend të caktuar operacionesh. Kur ekzekutohen së bashku, këto operacione do ta ngarkonin shumë makinën virtuale dhe do ta ngadalësonin në mënyrë disproporcionale ndaj tarifës që u pagua për ekzekutimin e këtyre operacioneve.
Në të kaluarën ka ekzistuar një periudhë e tillë zhvillimi të Ethereum, ku shumë njerëz që kishin njohuri të thella mbi funksionimin e makinës virtuale, gjenin këtë lloj dobësish. Në fakt, transaksionet paguanin një komision shumë të vogël, por ngadalësonin praktikisht funksionimin e tërë rrjetit. Këto probleme janë shumë të vështira për t'u zgjidhur, pasi duhet, së pari, të përcaktohen me saktësi, së dyti, të rregullohet çmimi për ekzekutimin e këtyre operacioneve dhe, së treti, të kryhet një hard fork, çka do të thotë përditësimi i të gjitha nyjeve të rrjetit në një version të ri të softuerit dhe pastaj aktivizimi i njëkohshëm i këtyre ndryshimeve.
Sa i përket Ethereum, janë kryer shumë hulumtime dhe është arritur një përvojë shumë e madhe praktike: si pozitive ashtu edhe negative, megjithatë mbeten ende vështirësi dhe dobësi me të cilat duhet akoma të luftohet në një farë mënyre.
Kështu, pjesa tematike e artikullit përfundon, le të kalojmë te pytjet që shfaqen mjaft shpesh.
Përgjigje të shpeshta
— Nëse të gjitha palët e kontratës smart që janë në fuqi duan të ndryshojnë kushtet, a mund të anulojnë këtë kontratë smart me ndihmën e shumë nënshkrimeve dhe pastaj të krijojnë një kontratë smart të re me kushte të përditësuara për realizimin e saj?
Në këtë rast, përgjigja do të jetë dyfishe. Pse? Sepse nga ana një, kontrata smart vendoset një herë dhe nuk parashikon ndonjë ndryshim, ndërsa nga ana tjetër, ajo mund të ketë logjikë të parashikuar me herët, e cila lejon ndryshimin e plotë ose të pjesshëm të disa kushteve. Pra, nëse dëshironi të ndryshoni diçka në kontratën tuaj smart, duhet ta keni parashikuar me herët kushtet sipas të cilave 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 ketu gjithashtu mund të hasni në probleme: të bëni ndonjë gabim dhe të keni një vulnerabilitet të përkatshëm. Prandaj, këto gjëra duhet të projektohen dhe testohen me shumë detaje dhe kujdes.
— Çfarë ndodh nëse ndërmjetësi bashkëpunon me një nga palët pjesëmarrëse: escrow ose kontratat smart? A është i detyrueshëm ndërmjetësi në kontratën smart?
Mediatori nuk është i detyrueshëm në kontratat inteligjente. Ai mund të mos jetë prezent. Nëse në rastin e escrow, mediatori bie në marrëveshje me një nga palët, atëherë, po, kjo skemë humb menjëherë gjithë vlerën e saj. Prandaj, mediatorët zgjidhen në një mënyrë që të besohen nga të gjitha palët e përfshira në këtë proces. Si pasojë, ju thjesht nuk do të transferoni moneda në adresën multisig me atë mediator që nuk e besoni.
— A është e mundur të transferoni shumë tokenë të ndryshëm nga adresa juaj në adresa të ndryshme synimi me një transaksion Ethereum, për shembull adresat e këmbimeve ku tregtohen këto tokenë?
Kjo është një pyetje e mirë dhe ka të bëjë me modelin e transaksioneve të Ethereum dhe dallimin e tij nga modeli i Bitcoin. Dallimi është thelbësor. Në modelin e transaksioneve të Ethereum, thjesht transferoni monedha nga një adresë në një tjetër, pa kthim, vetëm një shumë specifike që keni caktuar. Me fjalë të tjera, ky nuk është modeli i daljeve të papërdorura (UTXO), por modeli i llogarive dhe balancave përkatëse. Një transaksion mund të dërgojë disa tokena të ndryshëm në mënyrë teorike, nëse shkruani një kontratë të zgjuar, por gjithsesi do të nevojiten shumë transaksione, krijimi i kontratës, pastaj kalimi i tokenëve dhe monedhave, dhe më pas thirrja e metodës përkatëse. Kjo kërkon përpjekje dhe kohë, kështu që në praktikë kjo nuk funksionon kështu dhe të gjitha pagesat në Ethereum bëhen me transaksione të ndara.
— Një nga mite rreth platformës Ethereum është se nuk është e mundur të përshkruhen kushte që varen nga të dhënat e një burimi të jashtëm në internet, çfarë duhet bërë pastaj?
Zgjidhja qëndron në faktin se vetë kontrata smart mund të parashikojë një ose më shumë oracle të besuar, të cilët mbledhin të dhëna rreth gjendjes së gjërave në botën e jashtme dhe i transmetojnë ato në kontratat smart përmes metodave të veçanta. Kontrata vetë e konsideron të vërtetë atë informacion që merr nga palët e besuara. Për një besueshmëri më të madhe, zakonisht zgjedhin një grup më të madh oracle dhe minimizojnë rrezikun e komplotit të tyre. Kontrata vetë mund të mos marrë parasysh të dhënat nga oracle që janë në kundërvënie me shumicën.
Kjo temë i kushtohet një prej leksioneve të kursit online mbi Blockchain — “”.
Burimi: habr.com
