Razvoj blockchaina kroz oči backend developera

Dobar dan svima! Backend developmentom se bavim dosta dugo, a zadnjih nekoliko godina pišem sve više različitih blockchain projekata (Solidity on EVM). Ronjenje u blockchain nije mi bilo lako, a moj backend mozak se nekoliko puta pokvario, pa sam odlučio podijeliti svoje mišljenje o prelasku na blockchain razvoj.

Blockchain je vrlo cool tehnologija koja može pomaknuti naš svijet naprijed. Ali za sada ga mnogi ljudi koriste za kupnju-prodaju-prevaru-prijevaru-poticanje. Neću i ne planiram uzeti u obzir kripto kao sredstvo.

Da, mnogo različitih videa i postova kaže: “Evo, ta i ta kripto sada može rasti, a ta i ta kripto je pala. Ljudi, ajmo investirati, ajmo kupovati...” Neću vam ništa reći o tome.

Reći ću samo jednu stvar - trebali biste izbjegavati kripto za zarađivanje novca. Ako ste programer, bolje je pokušati zaraditi kao programer i ne upuštati se u ulaganja. A ako stvarno želite ulagati, nemojte ulaziti u kripto.

O blockchainu i zašto je zanimljiv

Vrijedi započeti s važnom napomenom. Blockchain nije kriptovaluta. Blockchain je tehnologija na kojoj je izgrađena kriptovaluta i nazvati kriptovalutu blockchainom je kao da cijelu razvojnu industriju nazovete Javascriptom . Da, čini se da je JavaScript poseban razvojni slučaj, ali kada govorimo o razvoju, ne mislimo na JavaScript. Iako neki ljudi misle samo na JavaScript...

Odlazak na blockchain za novac

Prvo što mi pada na pamet je novac. Blockchain programeri prilično su dobro plaćeni. Osobno sam otvarao takva radna mjesta. Osobno sam odgovarao na takve natječaje, gdje možete dobiti više od istog backend developera za istu količinu vremena provedenog dnevno na poslu. Blockchain programeri vrijede zlata u startupovima koji se temelje na blockchainu. Posebno dobar blockchain programer!

Tko je dobar backend programer?

Postati dobar backend developer nemoguće je bez ispuštanja ili popravljanja proizvoda. Možda sam samo gubitnik i učim samo kroz negativna iskustva, ali to je moja teorija:

1. Ako je backend programer iskusan, tada je pokrenuo rješenja u prod.
2. Ako ga je pokrenuo u Prod-u, onda zna kako radi i zna što se događa s proizvodom pod opterećenjem.
3. Ako je usluge držao pod opterećenjem, onda je uhvatio zastoje i padove usluga.
4. A ako je uhvatio servisne padove, vjerojatno ih je i pokupio.

Ne možete razmijeniti iskustvo s neuspjehom, ali iskustvo neuspjeha vam omogućuje da shvatite da imate iskustva. Teško je postati dobar blockchain programer bez gubitka novca:

• Ako mi još nisu ukrali novac iz ugovora, to znači da nisam pokrenuo nešto s pravim novcem (najmanje 1000 dolara na mom ugovoru).
• Ako nešto nisam lansirao s pravim novcem ili samo na testnim mrežama (s lažnim novcem), onda nemam pojma što me čeka u toksičnom svijetu blockchaina.
• Ako ne znam što me čeka, opeći ću se na prvom lansiranju, a pitanje je tima/tvrtke koja je spremna preuzeti rizik da bude prvi platitelj moje greške.

Ulazak u blockchain za tehnologiju

Gornja slika prikazuje prvi zrakoplov braće Wright na svijetu, koji leti prilično loše. Ali letio je, au svoje vrijeme stav prosječne osobe prema avionima bio je otprilike ovakav:

• Skup
• Nezgodan
• Nezgodno, neshvatljivo

A sada je zrakoplovna industrija prekrasan dio naših života, povezujući ljude diljem planeta u roku od nekoliko sati. Logistika je sada na razini o kojoj braća Wright nisu ni sanjala! Zbog aviona cijeli svijet živi drugačije.

Sada bih rekao isto za blockchain - skup je i nezgodan i nejasno zašto. Sve dok se nisam udubio u razvoj blockchaina, izgledao mi je kao nešto beskorisno za prevare investitora (=hrčke). Ali ako pogledate s druge strane, moguće je pohraniti bilo koju činjenicu na decentraliziran način bez mogućnosti petljanja. Ono “bez mogućnosti diranja” je važan detalj.

Ali nažalost, asocijacije na riječ "blockchain" prilično su dosadne i monotone:

• Bitcoin
• Ulaganje
• Prijevara
• ETH, Ripple, {insert coin name}
• Balon koji samo što nije puknuo

Ako u peć bacimo svežanj papirnatog novca, peć će dobro gorjeti, a novac će neko vrijeme čak i davati toplinu. Ali to je apsurdno.

A tako je i s blockchainom. Koristiti ga samo za novac i kripto je loše, ali ono drugo još ne pušta korijenje...

Jedan od glavnih pokretača razvoja svakog proizvoda je novac. Ako postoji nešto na čemu se može dobro i moćno zaraditi, onda će se to "nešto" aktivno razvijati. I zato se dosad financijski projekti temeljeni na blockchainu uistinu temelje na zarađivanju novca da bi netko zaradio novac i gubitku novca za nekoga drugoga.

Teorija razvoja lanca blokova

Decentralizacija

Koja je razlika između centralizirane i decentralizirane usluge? Počnimo s centraliziranim sustavom. Tu smo ja i još netko i odlučili smo upotrijebiti uslugu između nas, poput banke ili drugog pružatelja usluga, kako bismo olakšali prijenos.

Zamislimo da imamo banku, koja je centralizirana služba. Naređujem ovoj banci: "Molim vas prebacite 100 dolara ovoj osobi". Banka bilježi da ja imam 100 dolara manje, a netko drugi ima 100 dolara više.

Ali u čemu je problem s centraliziranom uslugom? Iza ove centralizirane usluge stoji vlasnik, zar ne? Obično neke velike tvrtke, holdingi, nema veze; u našem slučaju neka to bude jedna osoba. Ta jedna osoba može reći: “Učinimo to. Neka Alex pošalje 100 dolara, ali nitko neće primiti ovih 100 dolara. Trebam ih više”.

Centralizirane usluge imaju svoje vlasnike. Problem je u tome što vlasnik može donijeti negativne odluke, oduzeti novac. I ne može se raditi samo o "uzimanju novca za sebe". Na primjer, možete napisati, "Imamo 100.500 dolara u banci," i nadati se da svi štediše neće krenuti za tim novcem... kao što se dogodilo sa SVB i drugim bankama koje su umrle.

Bitcoin je izmišljen da decentralizira upravljanje novcem.

Decentralizirana usluga izgrađena je na mreži čvorova gdje svaki čvor pohranjuje i prenosi informacije. Jednostavno rečeno, čvorovi su se dogovorili koje se informacije smatraju točnima, a koje ne i kako ih pohranjujemo.

Možemo povući analogiju sa sobom - jedna osoba izvikuje informacije koje želi da ostali zadrže. Zatim, svi u prostoriji rade s informacijama koje su pohranili nakon vikanja.

Na primjer, blockchain može pohranjivati i prenositi poruke ili informacije o prijenosu novca. Sudionici u mreži provjeravaju informacije prije snimanja.

U analogiji sa sobom, viknem: "Prebacujem 100 dolara Samu." Svi bilježe da ja imam 100 dolara manje, a Sam ima 100 dolara više. Ako odjednom, prije prijenosa, imam manje od 100 dolara, nitko neće zabilježiti transakciju.

Pametni ugovori

U blockchainu možete kreirati pametne ugovore u jeziku Solidity (u slučaju blockchaina na EVM-u). Pametni ugovor je program koji radi na blockchain mreži. Može sadržavati mehanizme provjere valjanosti, rukovanje pogreškama i druge funkcije.

Opet, u slučaju sobe u kojoj izvikujemo naredbe, pametni ugovor je da svakom sudioniku u sobi unaprijed dajem programski kod: kako reagirati na moje naredbe, što provjeriti, a što spremiti. A onda viknem: "Izvrši program s ovim parametrima". Zatim svi slijede upute. Primjer jednostavnog, pametnog ugovora je pohrana informacija s funkcijama dodavanja i primanja podataka. Kod ugovora se kompilira u bajt kod i prosljeđuje sudionicima blockchaina na izvršenje.

Kako postupamo s određenim zahtjevima koji će biti poslani ovom pametnom ugovoru? Ako povučemo analogiju s backendom, to je servis koji može obraditi POST i GET zahtjeve. POST pohranjuje informacije. GET here šalje natrag podatke koje smo pohranili. Ovako je obično strukturiran bilo koji backend.

Tijekom mog razvoja na backendu, jako sam se navikao na dogovor da se API, baza podataka i sve što je povezano sa pohranjivanjem i obradom podataka odvija na mojoj strani. A ja već, kao iza zida, dajem sučelje za rad korisnika s tim podacima po unaprijed pripremljenom scenariju.

Na primjer, korisnik 1 dolazi i putem POST metode sprema sadržaj (npr. post). Zatim, korisnik 2 dolazi i dohvaća ovaj sadržaj koristeći GET metodu. Korisnici ne znaju gdje i kako leži – backend je za njih crna kutija.

I tu dolazimo do jednog vrlo važnog dijela blockchaina. Vratimo se našim primjerima čvorova ili ljudi koji stoje u sobi. Recimo, koristeći analogiju s pozadinom, svaki put imamo sljedeće: ubacujem metodu “ADD” u blockchain, a zatim svatko lokalno poziva metodu i zatim može uzeti informacije iz svoje kopije blockchaina.

Dakle, imamo hrpu različitih kopija u mreži iz kojih čvorovi preuzimaju informacije. Problem s blockchainom je taj što moramo platiti pravi novac za svaku operaciju pisanja. To se plaća valutom mreže, koja se može kupiti pravim novcem (ili rudariti, ali to nije ono o čemu danas govorimo).

Ako usporedimo blockchain i backend, slika je sljedeća:

• U konvencionalnim uslugama pišemo besplatno, čitamo besplatno i ovisno
• U blockchainu pišemo uz naknadu, a čitamo besplatno i neovisno

Na primjer, Telegram ima centraliziranu bazu podataka. Uvijek mu možemo besplatno pristupiti i preuzeti svoje poruke, fotografije, video zapise itd. Ali ako Telegramovi poslužitelji iznenada padnu, ne možemo mu pristupiti.

Moramo platiti za EVM virtualni stroj da izvrši neke naredbe pametnog ugovora, uključujući pisanje informacija u blockchain. Izvodi neke izračune, nešto zbraja, množi, množi, množi, i na kraju se novi artefakt pojavljuje u blockchain pohrani, koji se ažurira na svim čvorovima koji sudjeluju u blockchainu.

Svaki sudionik mreže može pokrenuti puni čvor sa stotinama gigabajta blockchain podataka i raditi s njim lokalno. Također možete koristiti laganu verziju čvora, koja neće pohraniti cijeli blockchain, ali možete pristupiti punim čvorovima u mreži i dohvatiti potrebne informacije preko njega.

Ideja je da je svaki unos u blockchainu blok koji sadrži hrpu transakcija u kojima dolazi do promjena u stanju blockchaina. Svaki sljedeći blok ovisi o prethodnom u lancu na temelju algoritama raspršivanja.

Općenito, to je osnovno, ali vrijedi imati na umu - morate platiti za svako kihanje ako se podaci mijenjaju. Usput, ugovorna implementacija također je rekord u blockchainu i nije jeftina!

Implementacija pametnog ugovora

U pozadinskom svijetu navikao sam otprilike na sljedeći životni ciklus razvoja značajki:

• Napisao šifru
• Pokrenuo ga u Gitlabu
• GitLab CI izvodi testove, provjerava sve
• Ako je sve u redu, CI počinje postavljati novu verziju aplikacije na poslužitelj

Odnosno, navikli smo raditi na ovaj način, a to se događa besplatno. Iako uvjetno besplatno, jer mi plaćamo servere. Što je s blockchainom?

U slučaju blockchaina, moramo napisati novi kod naše "aplikacije" (pametni ugovor) u blockchain. Kao što sam gore napisao, svaki zapis moramo platiti. Prije nego što izvršimo transakciju s našim pametnim ugovorom, moramo izvršiti transakciju s postavljanjem pametnog ugovora.

Zatim će klijent/servisni poslužitelj kontaktirati bilo koji od čvorova kako bi primio ili spremio informacije u ugovoru.

Ogroman broj čvorova treba biti obaviješten - "dečki, evo bajt koda ugovora čiji algoritmi moraju biti urađeni na mojim transakcijama". Neophodno je osigurati da se isti kod pojavljuje na svim čvorovima koji uče blockchain, te će se izvršiti na isti način, bez obzira tko ga poziva i bez obzira na to kako se zove. Mehanika će biti ista i nepromjenjiva. Nadalje, ne postoji način na koji se pametni ugovor može nekako promijeniti da radi drugačije na bilo kojem od čvorova.

Ispod je primjer transakcije u kojoj sam prije dosta vremena položio ugovor u ETH mrežu.

Bio je to probni ugovor koji nikada nije stvarno korišten. Platio sam 200 dolara u ETH za njegovu implementaciju. Odnosno, s ovim ugovorom još nismo ništa napravili - niti jedan zahtjev, ali 200 dolara je već potrošeno. Još uvijek sam tužan kad se sjetim ovog pogrešnog postavljanja krivog ugovora...

Pohrana podataka

Razgovarajmo o pohrani podataka. Svi smo navikli imati PostgreSQL , MySQL , MongoDB , Redis i druge usluge na pozadini koje nam omogućuju praktičan rad s podacima. U slučaju blockchaina, ne postoji ništa slično ni blizu.

U blockchainu, pohrana je implementirana poput varijabli u klasi u drugim jezicima. To jest, samo ključne vrijednosti ili nizovi. Ne postoje relacijske tablice s prikladnim vezama i tako dalje. Samo - pišite u varijablu i budite sretni.

U ovom trenutku ne znam ni za jedan drugi način organiziranja pohrane u blockchainu. Pa, možda se situacija već promijenila; možda, kada ovo čitate, postoji takav način - napišite u komentarima.

Na primjer, ako želimo pohraniti ne samo u niz? I želimo pohraniti informacije po ključu - za to postoji mapiranje.

Znak dolara nacrtan je s razlogom - mrežna provizija uzima se za svaki set.

Bolovi i bolovi

U ovom bloku raspravljat ću o stvarima koje su me iznenadile ili razljutile. Ima ih puno više nego što je u ovom dokumentu, ali podijelit ću prve stvari koje su me prve pogodile u mojoj praksi.

Važno je napomenuti da je većina "bolova" razumljiva iz nekog logičnog razloga. Ali to ne poništava bolove za moj stražnji mozak.

Na primjer, navikao sam na to da lako prolazimo kroz sve elemente bilo čega. Nije važno radi li se o nizu ili objektu ili karti. U Solidity-ju, u tu svrhu, morat ćemo odvojeno pohraniti niz svih ključeva, a zatim, ako je potrebno, proći kroz sve njih i dohvatiti elemente iz karte za svaki ključ. Pa, također trošimo gas na dodatno pisanje u ovaj niz ključeva i njegovu inicijalizaciju.

Ne možemo nabaviti ni sve praktične stvari za sortiranje ključeva.

Sječa drva

Neugodna je i situacija sa sječom. Navikao sam ispravljati pogreške putem programa za ispravljanje pogrešaka u razvojnom okruženju, ali ovdje biste trebali zaboraviti čak i na normalno bilježenje.

U Typescriptu sam navikao samo napisati console.log(a) i odmah dobiti izlaz u konzoli. U Solidityju postoji console.log koji radi samo kada se izvodi u lokalnom hardhat razvojnom okruženju . I ono što je sjajno jest da nakon što podijelim ono što trebam, moram izbrisati sve ove zapise prije implementacije ugovora jer u suprotnom, implementacija ugovora teži i košta više, a neće uopće raditi na proizvodu .

Na kraju se ispostavi da kada već pokrenemo projekt u borbi, želimo vidjeti što nije u redu, a ne možemo vidjeti što je pošlo po zlu. Ali možemo vidjeti što je bilo dobro. Postoji sustav događaja unutar pametnih ugovora. Evo primjera: recimo da želimo imati događaj u kojem je nova stavka dodana pod ovaj indeks s ovom vrijednošću.

Ovaj događaj pozivamo unutar metode set , a zapise možemo vidjeti samo kada se uspješno izvrši. Ako je nešto pošlo po zlu, imali ste višestruke pozive na ugovore ili smo imali pad transakcije, ni zapisnici se ne spremaju jer se informacije u lancu blokova vraćaju natrag.

Pretpostavimo da koristite lanac od nekoliko pametnih ugovora. Vi ste u prvom ugovoru pozvali neke događaje, onda se zove drugi ugovor koji poziva druge događaje i onda pada sve što je pozvano unutar drugog ugovora. Sve će biti potpuno izbrisano jednom zauvijek.

Moramo biti jako oprezni kada želimo zabilježiti što se događa unutar blockchaina i imati na umu da nam normalno zapisivanje, na koje smo navikli, ovdje jednostavno nije dostupno.

Još jedna gadna stvar je da ne možemo dobiti informacije iz naših transakcija u funkciji pisanja. Ako napravimo transakciju koja nešto upisuje u blockchain (tj. plaćenu transakciju), return neće dati ništa našoj usluzi koja se integrira s pametnim ugovorom. Ovaj povrat funkcionira samo unutar samog pametnog ugovora ili view (besplatnim) funkcijama.

Na primjer, željeli bismo da kada dodamo novu vrijednost u naš blockchain, možda želimo saznati veličinu pohrane nakon spremanja (gornji snimak zaslona). Odnosno, samo kroz događaje možemo saznati što je točno dodano. A da bismo to učinili, moramo povući događaje koji su pokrenuti unutar te transakcije.

Rad sa žicama

Tu me je dočekalo iznenađenje - nemoguće je normalno raditi sa žicama. Blockchain nije stvoren za nizove. Prijeđimo na primjere.

Kôd ispod će raditi bez ikakvih problema.

I ovaj kod više neće raditi:

Dugo sam navikao normalno raditi s nizovima, mijenjati znakove u nizovima, rezati nizove, spajati ih - sve to nije dostupno izvan kutije. Također ne postoji mogućnost prikaza duljine niza. Odnosno, ovaj kod se neće kompilirati:

Ako stvarno trebate duljinu niza, možete ga pretvoriti u bajtove i zatim prebrojati broj bajtova. Ali problem je što se neki posebni znakovi ne pretvaraju u bajtove 1v1. A neki jednostavno nisu pretvoreni i transakcija se može srušiti.

Na kraju biste mogli napisati pametni ugovor koji obrađuje nizove i testira normalne nizove. Tada će stići string koji neće biti obrađen, pa će se sve srušiti ili će dužina niza biti netočno prebrojana zbog posebnih znakova.

Zaključak o stringovima je jednostavan: nemojte raditi sa stringovima i nemojte se oslanjati na stringove unutar ugovora. Ako je važno spremiti stringove, onda spremite bajtove i oslonite se na bajtove, a stringove pretvorite u bajtove na samoj usluzi.

Problem s vanjskim pozivom

Sljedeća složenost, koja je proširenje glavne značajke blockchaina, je izolacija. Svi podaci koji se nalaze na blockchainu rođeni su unutar blockchaina ili se u njega prenose izvana. Ali sam blockchain nikada ne može zakucati na vanjski svijet - samo drugi pametni ugovori.

Problem je što se sve naredbe pametnog ugovora izvršavaju na svakom sudioniku u mreži. I ne možete vjerovati vanjskom izvoru, jer ne možete biti sigurni da će iste informacije biti primljene na svakom čvoru. Dogodit će se da će svaki čvor imati drugačiju verziju blockchaina s različitim podacima i blockchain će propasti.

I trivijalni zadatak "odmjeriti trenutnu vanjsku temperaturu" postaje nešto nemoguće. Iako nam vremenska prognoza nije uvijek potrebna, neki podaci (kao što su tečajevi valuta ili trenutno stanje nekog vanjskog sustava) su bitni. Rješenje leži u sljedećem pristupu:

1. Imamo ugovor s operaterom, gdje naša usluga šalje zadatak poput "podnesite zahtjev ovom poslužitelju s takvim i takvim parametrima".
2. Ugovor emitira događaj
3. Zasebna pozadina pretplaćuje se na ovaj događaj, izvlači informacije iz događaja, što kaže "gdje i s kojim parametrima poslati zahtjev" i odgovor "stavite to ovdje u ovaj ugovor".
4. Server šalje zahtjev s pravim parametrima, dobiva odgovor
5. Server šalje odgovor na traženi ugovor.
6. Ono što se sljedeće događa je ono što bi se trebalo dogoditi s ovim podacima.

Ispada tako dugačak lanac. Žalosno u priči je to što se novac uzima na moj prvi zahtjev forme “idi mi na takav zahtjev” i na drugi zahtjev, što već radi server koji je izvršio zahtjev.

Na primjer, potrebno nam je 50 tisuća goriva za svaki korak. Započnemo transakciju, stavimo 50k GAS LIMIT i mislimo da ćemo biti u redu. Ali, primjerice, mijenja se mehanika spremanja novog vremena - sada, kada je temperatura iznad 10 stupnjeva, trebamo prebaciti novac nekom od sudionika. Logika se širi, pa će sada trebati npr. 80 tisuća plina po transakciji.

Na kraju, već na drugoj transakciji, cijeli lanac propada zbog nedostatka plina za transakciju. Takav "povrtnjak" oko vanjskih poziva čini takve projekte kompliciranijima. Najvjerojatnije, ako imate čvrstu vezu s vanjskim svijetom, ne biste trebali odabrati blockchain za svoj projekt.

Također ne postoji normalna slučajnost koja se ne može unaprijed odrediti. Ovu nasumičnost također pružaju različiti pružatelji usluga "kao što jest" - samo se nasumična vrijednost redovito upisuje u pametni ugovor. Ali opasno je vjerovati takvo što za prave financijske projekte.

Posebnu pažnju zaslužuje činjenica da vrijednost varijable block.timestamp postavlja rudar blokova. Naravno, teško je zamisliti da će rudar unaprijed znati da je on taj koji rudari blok i može zamijeniti vrijeme. Ipak, postoji hipotetska mogućnost. Ova opasnost je relevantna u kontekstu 15 sekundi, a ako se oslanjamo na minute i velike vremenske intervale, tog problema nema.

Sigurnosna pitanja

O sigurnosti ne planiram puno govoriti. Ali naglasit ću važan aspekt: sve u blockchainu je vidljivo svima. Jedina stvar koja je nedostupna drugima je vaš privatni ključ. Kod pametnog ugovora javno je otvoren kako bi prošao revizije i kako bi mu korisnici pametnog ugovora mogli vjerovati.

Revizijski postupak znači da je tvrtka angažirana da pogleda šifru pametnog ugovora i potvrdi da je ovaj određeni ugovor objavljen na ovoj adresi. Pitanje sigurnosti ugovora se provjerava i radi ono što programeri deklariraju. Zatim, revizorska tvrtka objavljuje informacije poput "mi smo provjerili ovaj ugovor - može mu se vjerovati" na svojoj web stranici.

Nepromjenjive varijable

Ali čak i ako kod ugovora nije naveden, može se lako dekompilirati. Na primjer, sljedeći kod ima nepromjenjivu varijablu - jednostavno je posvuda zamijenjena konstantom u donjem kodu.

Nakon postavljanja ovog ugovora i otvaranja kroz dekompilator, vidimo sljedeće:

To jest, ovu vrijednost varijable dobivamo odmah.

Privatne varijable

Navikao sam da mogu biti miran u pozadini, a vrijednost privatnih varijabli za čitanje bez pristupa memoriji bit će problematična. I ovdje je tako - samo svi imaju pristup “memoriju”.

Promjenjivi amount nazvali smo privatnim. Implementirajte pametni ugovor, a zatim izvucite njegovu vrijednost jednostavnim isječkom koda:

Na kraju možete izvući bilo što na taj način. Stoga nemojte razmišljati o pohranjivanju bilo čega osjetljivog u pametni ugovor!

Implementacija pametnog ugovora

U osnovi je nemoguće vratiti vaše promjene. Pametni ugovor se jednom dodjeljuje i ništa se ne može promijeniti. Ostat će na blockchainu do kraja vremena, a zatim još malo.

Nadogradivi pametni ugovori

Zato moraš odjednom sve ispravno i dobro napisati. Ja to ne mogu, pa sam se brzo dosjetio zanimljivog rješenja - Nadogradivi ugovori . Njihova mehanika radi na sljedeći način.

1. Objavljena je prva verzija ugovora (Ugovor V1).

2. Proxy ugovor je objavljen i ima sljedeći zadatak: proslijediti sve zahtjeve 1v1 Ugovoru V1 ili koristiti vlastitu pohranu i koristiti samo logiku iz ciljnog ugovora.

3. Nadalje, korisnik komunicira s proxy ugovorom na isti način kao i s glavnim.

   Ako je potrebno ažurirati ugovor, administrator postavlja Ugovor V2 i, putem admin-ugovora, govori proxy-ugovoru da je implementacija sada na adresi Ugovora V2.

4. Zatim, korisnik također komunicira s proxyjem, a mehanike iz ugovora V2 već su izvršene.

5. Zatim, korisnik također komunicira s proxyjem, a mehanika ugovora V2 već je izvršena.

Ovaj mehanizam ima niz ograničenja i trikova. Na primjer, varijable iz prethodne verzije ne mogu se mijenjati u novoj verziji ugovora. Ako varijabla više nije potrebna, mora se ostaviti i depopulirati u novi ugovor.

Naravno, ovo rješenje i mnoga druga već imaju gotova rješenja. Glavni dobavljač ovih razvoja je OpenZeppelin . Stoga, srećom, nema potrebe ponovno izmišljati kotač.