Kako izgleda naš Web3 Tech Stack i zašto iskustvo u njemu nije presudno

Kako izgleda naš Web3 Tech Stack i zašto iskustvo u njemu nije presudno

Odmah da napomenem, ovo neće biti uobičajen tekst o tech stacku. Nema “ako radiš ovo, potrebno ti je ovo, ovo i ovo” jednodimenzionalnog pristupa.

Štaviše, možda vam se na trenutke učini da ovo uopšte nije tekst o tech stacku, ali bez brige, jeste, samo fokus neće biti direktno na njemu. Zašto je tako, biće vam jasno na samom kraju teksta.

Termin “Web3” se često objašnjava uz mlataranje rukama ili kompleksnim tekstovima o značaju decentralizacije — gravitacionoj tački Web3 univerzuma.

Takođe i mimovima, koji zbog složenosti i internog humora čine ne-Web3 ljude još više zbunjenim.

Da uozbiljim stvari, kako god objašnjavali Web3, cilj je predstaviti težnju ovog pokreta da korisnicima interneta vrati ono što je njihovo — slobodu i sigurnost imovine i podataka. I pritom im pruži dosta toga inovativnog i korisnog.

Decentralizacija tu uskače kao faktor koji raščišćava sve ono nepotrebno, skupo i neefikasno koje se nalazi između strana koje žele da završe neki posao. Recimo običan transfer novca od A do B.

Međutim, postavlja se pitanje kako izgleda tehnička strana rada na nečemu što je ideološki i vrednosno suprotno od web2? Da li to nužno znači da i tehnologija mora biti drugačija? Šta su čekić, klješta i šrafciger Web3-ja?

U prevodu, kako izgleda stack prosečnog Web3 projekta?

Za početak, da se osvrnemo na samu tehnologiju na kojoj počiva Web3 — blokčejn.

Objasniti blokčejn je klizav teren pogotovo kada stručnjak ne baš vičan komunikaciji objašnjava laiku ne baš sklonom tehnologiji. Jezik blokčejna je složen i usko stručan. Sa druge strane, analogije iz poznatog okruženja nisu baš najpreciznije pa se često može pogrešno preneti poruka.

Naša wikipedija, na primer, kaže: blokčejn je distribuirana baza podataka sačinjena od manjih baza (blokova) koje su međusobno povezane, a koje sadrže informacije o digitalnim transakcijama bilo koje vrste.

I odmah začkoljica. Pomisliti na tradicionalnu bazu podataka može da vodi pogrešnom zaključku. Iako jesu vrsta baze podataka, decentralizovani blokčejnovi nisu optimalne strukture za čuvanje proizvoljnih podataka kao tradicionalne baze. Neefikasno i skupo je, na primer, čuvati video ili sliku na blokčejnu.

Dakle, bitno je razumeti da blokčejn nije zamena tradicionalnoj bazi podataka. Podaci moraju biti sačuvani na njemu, ali ne doslovno, tj. u potpunosti..

Umesto toga, dovoljno je da od trajnih podataka na blokčejnu možemo da izvedemo sve ostale. To znači da se osnovni podaci (balansi korisnika ili vlasništvo nekog) čuvaju 1:1 na lancu, a da se za kompleksnije podatke blokčejn koristi kao validator.

Pritom se kao izvor podataka za frontend koristi njihova agregirana, indeksirana i nadograđena verzija koju održava eksterni servis. Ono što je dodatno bitno je ne oslanjati se na jedan izvor istine jer taj izvor lako može da nestane.

Uzmimo štednju za primer. Sistem čuva osnovni balans korisnika u početnom trenutku, i množilac za kamatu koji se povećava na svakih X blokova. Do ostalih podataka dolazimo posredno. Da bismo dobili trenutni balans nekog korisnika, koristimo njegov osnovni balans i množilac kamate u željenom trenutku.

Međutim, ako hoćemo da vidimo kretanje balansa kroz vreme, ili balans u određenom trenutku, potreban je servis koji bi prošao kroz sve istorijske blokove i sačuvao vrednost množioca u tom trenutku. Za ovakve slučajeve stvoren je The Graph protokol, koji agregira podatke na proizvoljan način. Frontend dalje komunicira sa Graph nodovima, ali je blokčejn originalni izvor podataka.

Drugi primer su NFT-jevi čije se vizuelne komponente (slika, video...) usled orgomne količine podataka ne čuvaju na samom blokčejnu. Umesto toga, čuva se IPFS heš (njegov identifikator) koji jednoznačno odgovara sadržaju, a pomoću kog se sam fajl može pronaći na distribuiranoj IPFS mreži.

Sad kada imamo ideju kako se podaci prikupljaju, čuvaju i kako se njima upravlja, prelazimo na organizaciju tehničkih timova.

Timovi Decentera

U Decenteru postoje 3 tech tima sa ukupno 14 ljudi. Taj broj predstavlja ⅔ čitavog kolektiva. Ostatak su marketing i support.

Tech timovi su:

Timove ne bi trebalo zamišljati kao silose. Iako svaki tim ima svoj domen, nema jasnog razdvajanja, štaviše, povezaniji su nego web 2 timovi. Međuzavisnost je izražena budući da je neophodno da većina ljudi razume i ostale delove stack-a.

Backend tech stack

“Koliko sam ja razumeo tu decentralizaciju, treba da pogasim sve servere i obrišem svoje MySQL tabele.”

Teoretski da, u praksi ne sasvim. Zaista, Ključni Princip* dizajna decentralizovanih aplikacija kaže da bi sve trebalo da funkcioniše besprekorno čak i ako tvoj server padne ili Amazon odluči da obriše sve instance koje imaju veze s kripto tehnologijom.

Dakle sav tvoj kod — pogotovo backend — preuzima supporting ulogu da aplikacija radi efikasnije, ali je ideja da može da radi i bez njega.

Još jedno polje gde backend više nema glavnu ulogu je autentifikacija korisnika. U Web2, korisnik je obično identifikovan email adresom ili brojem telefona, a autentifikovan šifrom uz aminovanje bekenda koji je upoređivao tu šifru sa heširanom kopijom u bazi.

Jasno je da se ovo višestruko kosi sa Ključnim Principom. Umesto toga, korisnik je sada identifikovan svojim novčanikom, a autentifikuje se tako što potpisuje stvari privatnim ključem.

“Super, ali šta onda radi backend?”

Neko iz Decentera je skoro imao trenutak prosvetljenja: “Sve vreme sam ubeđivao ljude da programiranje nije gledanje u terminale i brojeve kao na filmovima, a onda sam došao ovde i shvatam da ipak jeste”.

Verovatno ste čuli kako se u kripto svetu dosta ljudi bavi pisanjem botova za trejdovanje. Oni uglavnom pišu botove koji komuniciraju sa različitim menjačnicama i pokušavaju da naprave pobedničke strategije.

Iako suštinski različito, ono što se radi u Decenteru ima dodirnih tačaka sa prethodno pomenutim primerom. Takođe se pišu botovi, ali oni rade u web3 svetu, konkretno na Ethereumu, i nemaju za cilj da naprave pobedničke strategije već da podrže što više različitih strategija koje su korisniku na raspolaganju.

Glavne razlika u pristupima su:

1. Ne postoji kontrola nad tuđim novcem ni u jednom trenutku;

2. Pre bekenda postoji sloj pametnih ugovora koje kuca Solidity tim, ne dozvoljavajući da bilo ko (pa i sam i backend) uradi nešto maliciozno ili neželjeno po korisnika;

3. Konstantno se prati Ethereum mreža (kao i Arbitrum i Optimism trenutno) i kada se određeni uslovi ispune, spajaju se “složene transakcije” koje rade ono što je korisnik predvideo (uglavnom ih spasavaju od likvidacije na jedan od nekoliko načina).

Međutim, ove razlike donose složene izazove. Potrebno je učiniti transakcije jeftinijim (potrošiti što manje gasa) i neophodna je stalna redundantnost — Ethereum radi 24/7 za razliku od nas.

Na kraju, tehnologija je mlada, samim tim nestabilna i potreban je  dodatan trud da se pokriju svi krajnji slučajevi kako bi se moglo reći “ok, sad za sve imamo backup”.

Od tehnologija se uglavnom koristi Golang. Iako relativno mlad jezik (13 godina) našao je svoje mesto u stacku velikih kompanija, a u Web3 ekosistemu je dominantan. Bez obzira na nešto drugačiju paradigmu, praksa pokazuje da se relativno brzo uči i ljudi se prosto “navuku” na njega.

Naravno, određene situacije zahtevaju drugačije pristupe koji će efikasnije rešiti problem. Drugi programski jezici su dobrodošli u ovaj dom.

TL;DR backend tech stack: Golang + šta je najprimerenije datoj situaciji

Frontend tech stack

Tradicionalno, frontend je na polju autentifikacije prosleđivao dve vrednosti iz login forme i prepuštao logiku bekendu.

U Web3-ju, dosta odgovornosti se premešta na frontend jer, sve mora (tj. trebalo bi da može, hvala Ključnom Principu) da radi bez bekenda. Dosta DApp-ova je suštinski kombinacija sistema pametnih ugovora i frontenda koji s njima interaguje.

Frontend, u ovim slučajevima, dohvata podatke direktno sa lanca, formatira ih i prikazuje. Ovo u praksi dosta liči na prosečnu Web2 aplikaciju. To je najćešće obična React aplikacija koja, umesto sa REST API-ja, vuče podatke sa pametnih ugovora kroz RPC, tj. API Ethereum noda.

Za programera to znači da ne koristi fetch, već neku biblioteku koja apstrahuje komunikaciju s Eth nodom kao što je web3.js ili ethers.js.

Primer:

Web2

const balance = await fetch(API_URL + '/balances/' + userAddress)

Web3

const savingsContract = new web3.eth.Contract(SAVINGS_ADDRESS, SAVINGS_ABI);
const balance = await savingsContract.methods.balance(userAddress).call();

Pored rukovanja podacima, frontend je direktno odgovoran za svaku interakciju sa pametnim ugovorima. Odgovornost je utoliko veća kada uzmemo u obzir da većina ovih interakcija ima i finansijski aspekt, bilo da je reč o transakcijama unutar DeFi ekosistema ili radu sa NFT-jevima.

Uzevši u obzir da aplikacija ne treba da zavisi ni od jednog servera, pa ni onog koji prosto servira statičke JS fajlove, frontendi kompletno decentralizovanih aplikacija su najčešće open source. To znači da je, ukoliko se desi bilo kakav desi poremećaj u funkcionisanju (pad AWS-a npr), neophodno da korisnici uvek mogu da ih pokrenu sami.

TL;DR frontend tech stack: JavaScript, React, Redux, web3.js, ethers.js

Solidity


Suština svake decentralizovane aplikacije su pametni ugovori koji se pišu u programskom jeziku Solidity. I ugovore i Solidity smo detaljnije već obrađivali u posebnim tekstovima, pa ćemo ovde navesti samo najznačajnije činjenice.

Solidity je objektno orijentisan programski jezik koji, dakle, služi za pisanje pametnih ugovora za Ethereum blockchain.

Sa druge strane, pametni ugovori su računarski kod koji se hostuje i automatski izvršava na vrhu blokčejna kada se ispune predefinisani uslovi. Ključno je zapamtiti da su pametni ugovori jezgro svakog decentralizovanog sistema i da su zaduženi za formalizovanje i sprovođenje njegove logike i čuvanje stanja.

Dosta mehanizama na koje programeri pametnih ugovora moraju da se naviknu je različito od tradicionalnog programiranja. Pametni ugovori ne praštaju greške i potrebno je full time posvećivanje u radu. Pod tim se misli na konstantnu edukaciju ne samo u razvoju jezika već i u praćenju novih tipova napada kako bi ugovori koje programer piše bili adekvatni za produkciju i ujedno bezbedni.

Traženje bezbednosnih propusta je veliki deo posla Solidity programera što izazovnost ovog posla diže na dodatni nivo. Kako projekti rastu i postaju kompleksniji, propusti su sve češći.

Problem bezbednosti je do te mere izražen da su se čak i sami kreatori Ethereuma ozbiljno sapleli. Poznata je priča o DAO haku iz 2016. godine kada je zbog baga u kodu ukradena količina Ethera u vrednosti 50 miliona dolara.

Još jedna od uloga Solidity tima je pisanje testova i briga o čistom i jasnom kodu. Pametni ugovori su open-source i transparentnost je preduslov za verodostojnost i ozbiljnost svake decentralizovane aplikacije. U ekosistemu se izuzetno obraća pažnja na detalje i granične slučajeve.

TL;DR: Solidity, ako do sad nije bilo jasno.

P. S. budući da je Solidity relativno nova tehnologija, bitno je napomenuti da se za nove zaposlene u Decenteru ne potencira na iskustvu u ovom jeziku.

Ne samo za Solidity tim, već uopšteno, fokus je na ljudima koji imaju dubinsko znanje arhitekture računara i programskih jezika. Iskustva u jezicima kao sto su C, C++, Go i Rust su idealna osnova. U ovoj sferi je najlakši logički prelaz sa low level programskih jezika. Zbog toga, svi koji ih poznaju, imaju blagu prednost kada je u pitanju učenje Solidity-ja.

Web3 iskustvo: nema kvake 22

Kao i za konkretan slučaj Solidity-ja, iskustvo rada u web3 svetu nije preduslov da se postane član Decentera. Štaviše, akcenat je na ljudima koji imaju sistemsko predznanje ali i entuzijazam da, upravo ovde, upijaju iskustvo i razvijaju se u vrhunske Web3 stručnjake.

S tim u vezi treba napomenuti šta je zaista game changer kada već iskustvo to nije.

Za početak, prepoznavanje problema koje sa sobom nosi Web2 i velika zainteresovanost za mogućnosti koje Web3 pruža u prevazilaženju istih su jasan prvi signal.

Najveća razlika je razumevanje suštine Web3 pokreta, njegovih specifičnosti, paradigmi i principa. Samim tim, za programere koji žele da pređu u Web3, potrebno je interesovanje i istraživački duh, kao I fleksibilnost da poznate tehnologije primene u manje poznatom okruženju.

Shvatanje suštine decentralizacije značajno doprinosi — kada postoji jasno “why” i “how'' sve postaje mnogo lakše. I to je ono što se traži.

Međutim, od trenutka kada se započne web3 karijera, želja za daljim proučavanjem blokčejn tehnologije, a naročito Ethereuma do detalja, u velikoj meri određuje da li će neko postati vrhunski web3 developer.

Kao što je pomunuto, rad u Web3 timu podrazumeva da svi razumeju sve delove stack-a, što znači da istraživanje Solidity-a kao jezika specifičnog za Web3 daje dobar uvid u sve što radimo. Tj. iako možda nikad nećete pisati Solidity kod, sigurno će vam biti neophodno da ga odlično razumete.

Interesuje me, ali ne znam odakle da krenem

Posmatrano sa strane, kripto svet je vrtoglav. Visoka kompleksnost ekosistema, mnogo informacija, stalne promene, svakodnevni izazovi i nova rešenja — to je za mnoge obeshrabrujuće da bi načinili prvi korak. Pa čak i u slučaju da im deluje interesantno.

Posmatrano iznutra, zaista jeste tako. Nekad i haotičnije od toga čak; pravi rolerkoster. Međutim, svako ko se osmeli da krene napred treba da bude ohrabren i uveren da na tom putu neće biti sam. Web3 ljudi su po pravilu izrazito voljni da dele svoje znanje iz razloga jer rast svakog pojedinca može da znači i razvoj čitave zajednice.

Svako ko je zainteresovan za blockchain, a ne zna odakle da krene, nek pogleda Decenterovu listu sa resursima koja se ne ograničava samo na kripto. Nek čitanje kvalitetnih tekstova i knjiga i gledanja predavanja budu tvoji prvi koraci ka lansiranju u ovaj uzbudljivi svet.

Uzgred, Decenter je ove godine započeo sa studentskim praksama. Prva generacija studenata je upravo završila posao veoma uspešno. Narednu dočekujemo već sledećeg leta.

Za više saveta kakve zadatke možete samostalno da radite da biste se oprobali u web3 svetu, pratite naš blog i Linkedin.

*U pisanju tekstu umnogome pomogli Jelena Koren, Nikola Klipa i Nikola Vuković koji je i tvorac termina Ključni princip.