Ako želite postati blockchain developer i pisati pametne ugovore na Ethereumu, morate razumjeti da ne učite samo novi programski jezik, nego ulazite u potpuno drugačiji računarski model: decentraliziranu, permissionless virtualnu mašinu gdje svaka linija koda izravno upravlja stvarnom vrijednošću. Pametni ugovori već danas pokreću decentralizirane burze, sustave kreditiranja, NFT tržišta i RWA protokole – i sve to na javnoj, transparentnoj mreži koju nitko centralno ne kontrolira.
Za razliku od klasičnog web backend-a, gdje bug znači pad servisa ili izgubljene podatke, na Ethereumu bug može značiti nepovratno zaključana sredstva ili drastičan gubitak korisničkih depozita. Upravo zato svaka odluka u dizajnu i implementaciji pametnog ugovora ima težinu – od izbora tipova podataka do načina upravljanja pravima pristupa.
Osnovni koncepti: računanje, gas i EVM
Ethereum pametni ugovori izvršavaju se na Ethereum Virtual Machine (EVM), determinističkoj virtualnoj mašini koju paralelno pokreću tisuće čvorova diljem svijeta. Svaka operacija u EVM-u ima svoju cijenu izraženu u gasu, a gas se plaća u ETH-u. To znači da dizajn koda nije samo akademsko pitanje – izravno utječe na trošak korištenja vašeg protokola.
Gas postoji kako bi spriječio beskonačne petlje i zloupotrebu resursa mreže. Ako transakcija potroši sav dodijeljeni gas prije završetka, izvršavanje se revert-a, ali gas ostaje potrošen. Kao developer morate balansirati između čitljivosti koda i optimizacije: primjerice, čitanje iz storage-a (SLOAD) višestruko je skuplje od čitanja iz memory ja.
Još jedna ključna razlika u odnosu na tradicionalne sustave jest to da pametni ugovor nema pristup vanjskom svijetu (HTTP, baze podataka, filesystem). Sve što vidi je globalno stanje blockchaina, ulazni podaci transakcije i nekoliko predefiniranih vrijednosti (block.timestamp, msg.sender, msg.value…). Za sve podatke izvan lanca koriste se orakli (Chainlink i slični), ali oni uvode dodatne rizike i točke povjerenja koje morate razumjeti prije integracije.
Solidity – jezik pametnih ugovora
Najrašireniji jezik za razvoj pametnih ugovora na Ethereumu je Solidity, sintaksom sličan JavaScriptu i C++-u, ali s izrazito strogo definiranim tipovima i specifičnim modelom memorije. Postoje tri glavna segmenta memorije: storage (trajni, skup), memory (privremeni, jeftiniji) i calldata (read-only ulaz). Razumijevanje razlike između njih ključno je za optimizaciju gas troškova.
Tipičan minimalni pametni ugovor u Solidityju izgleda ovako:
pragma solidity ^0.8.20;
contract SimpleStorage {
uint256 private value;
function set(uint256 _value) external {
value = _value;
}
function get() external view returns (uint256) {
return value;
}
}
Ovdje vidite nekoliko osnovnih pojmova: pragma definira verziju kompajlera, contract uvodi novi tip koji se na lancu ponaša kao račun (account), a funkcije imaju modifikatore vidljivosti (external, public, internal, private) i tipove funkcija (view, pure, payable). Zanemarivanje tih detalja često vodi do grešaka, poput neželjenog izlaganja interne logike ili nemogućnosti primanja ETH-a.
Za većinu ozbiljnijih protokola danas se koristi kombinacija Solidity + provjerene biblioteke poput OpenZeppelin Contracts, koje nude battle-tested implementacije token standarda (ERC-20, ERC-721, ERC-4626), upravljanja pristupom (AccessControl) i sigurnosnih paterna (Pausable, ReentrancyGuard).
Razvojni alati i okruženje
Dobar blockchain developer danas ne piše pametne ugovore “u prazno”, već koristi cjelovit ekosustav razvojnih alata. Najčešći stack uključuje Hardhat ili Foundry kao framework, Metamask ili drugi Web3 novčanici za interakciju, te Ethers.js ili viem za integraciju s frontend-om.
Hardhat je JavaScript/TypeScript-based framework koji nudi lokalni EVM nod, deploy skripte, fixture-e za testiranje i pluginove za verifikaciju koda na Etherscan-u. Foundry je noviji, ali izrazito performantni Rust-based alat koji koristi Solidity za pisanje testova (Forge) i nudi brze fuzz testove i property-based testing.
Tipičan workflow izgleda ovako:
1. Definirate specifikaciju protokola (funkcionalni i sigurnosni zahtjevi).
2. Implementirate ugovore u /contracts direktoriju.
3. Pišete unit i integracijske testove u /test (npr. Hardhat + Mocha/Chai ili Foundry + Forge).
4. Pokrećete lokalni nod, deployate ugovor i testirate interakcije.
5. Nakon toga slijedi deploy na testnet (Goerli, Sepolia ili Layer 2 mreže) i tek na kraju na mainnet.
Kako pametni ugovor zaista radi na lancu
Kada deployate pametni ugovor, zapravo šaljete transakciju bez primatelja (to je tzv. contract creation transaction) koja sadrži kompajlirani EVM bytecode i opcionalni constructor argumente. Nakon što validator ili minter blokova potvrdi transakciju, ugovor dobiva svoju adresu, deterministički izračunatu na temelju adrese pošiljatelja i njegovog nonce-a.
Svaki poziv funkcije u ugovoru je transakcija ili intern call. Ako korisnik pozove funkciju putem Metamaska, njegov novčanik kreira transakciju s poljem to = adresa ugovora i data = ABI-enkodirani selector funkcije + parametri. EVM na svakom čvoru dekodira data, pronalazi odgovarajući function selector (prva 4 bajta Keccak-256 hasha potpisa funkcije) i izvršava bytecode.
Unutar izvršavanja, kod može:
– čitati i pisati u svoj storage preko SSTORE i SLOAD instrukcija
– slati ETH i pozivati druge ugovore preko call, delegatecall, staticcall
– emitirati evente (logovi) koje backend servisi koriste za indeksiranje
Važno ograničenje je da izvršavanje mora biti determinističko i nezavisno od vanjskih izvora. Zbog toga ne možete koristiti random() ili API pozive – za pseudo-slučajne vrijednosti koriste se kombinacije blockhash, timestamp i drugih on-chain podataka, ili specijalizirani VRF orakli ako vam treba kriptografski sigurna nasumičnost.
Primjer: jednostavan ERC-20 token s dodatnom logikom
Razvoj pametnih ugovora ne svodi se na copy-paste standarda. Recimo da želite stvoriti ERC-20 token koji uz osnovne funkcije ima i mogućnost “zamrzavanja” transfera u slučaju incidenta. Najsigurniji pristup je naslanjanje na OpenZeppelin ERC20 implementaciju i dodavanje kontrollnih slojeva.
Primjerice
– koristite ERC20 kao baznu klasu
– dodajete modifikator onlyRole(DEFAULT_ADMIN_ROLE)
– uvodite bool varijablu transfersPaused u storage
– definirate modifikator whenTransfersNotPaused koji se primjenjuje na transfer funkcije
Na ovaj način ne pokušavate reinventati osnovnu logiku salda i transfera, nego se fokusirate na specifičnu poslovnu logiku. Ipak, morate razmišljati i o governance aspektu: tko ima admin rolu, kako se ona prenosi, postoji li multi-sig ili DAO glasanje kako bi se smanjio centralizirani rizik.
Isti princip vrijedi za složenije DeFi protokole poput Uniswapa, Aavea ili Compounda – oni su skup međusobno povezanih pametnih ugovora koji definiraju kako se likvidnost deposit-a, kolateral i pozicije upravljaju i ažuriraju pri svakoj transakciji.
Sigurnosni rizici i česte greške
Postati blockchain developer znači naučiti razmišljati kao napadač. Najpoznatiji sigurnosni rizik je reentrancy, gdje zlonamjerni ugovor koristi callback da ponovno pozove funkciju prije nego što se završi prethodno stanje. Klasičan primjer: funkcija prvo šalje ETH korisniku, a tek onda ažurira njegov saldo – napadač tijekom poziva fallback funkcije ponovno poziva istu funkciju i povlači sredstva više puta.
Drugi veliki rizik je integer overflow/underflow, koji je u velikoj mjeri mitigiran u modernim verzijama Solidityja (0.8.x) ugrađenim sigurnosnim provjerama. Ipak, ako koristite inline assembly ili kompatibilnost s prijašnjim verzijama, morate eksplicitno koristiti SafeMath ili ručno provjeravati granice.
Pored tehničkih bugova, postoje i dizajnerski rizici:
1. Centralizirana administracija: ako jedan ključ može pauzirati protokol, promijeniti naknade ili preusmjeriti sredstva, korisnici su izloženi riziku kompromitacije ili zlouporabe tog ključa. Rješenje su multi-sig novčanici, timelock ugovori i on-chain governance.
2. Loše postavljena ekonomija protokola: ako pametni ugovor ne ograniči maksimalnu emisiju tokena ili dopušta nepredviđene mint operacije, možete stvoriti neodrživu inflaciju ili mogućnost manipulacije tržištem. Primjer su projekti gdje admin može arbitrarnim mintom obezvrijediti postojeće tokene.
Najbolje prakse: testiranje, audit i verzioniranje
Profesionalni razvoj pametnih ugovora podrazumijeva sustavno testiranje. To znači:
– unit testove za svaku funkciju i edge case
– integracijske testove s drugim ugovorima
– fuzz testing za nasumične ulaze
– simulaciju napada (reentrancy, flash-loan, oracle manipulacija)
Alati poput Foundryja omogućuju vam da u potpunosti iskoristite property-based testing, gdje definirate svojstva koja uvijek moraju vrijediti (npr. ukupna suma salda korisnika nikad ne prelazi totalSupply) i automatski generirate tisuće slučajeva.
Audit od nezavisne sigurnosne firme nije garancija apsolutne sigurnosti, ali je praktički industrijski standard za protokole koji upravljaju značajnom količinom kapitala. Audit izvještaji često pokrivaju i logičke ranjivosti i ekonomske napade, ne samo trivijalne bugove.
Kako je kod na lancu u pravilu nepromjenjiv, potrebno je razmišljati o nadogradivosti. U praksi se koriste proxy paterni (Transparent Proxy, UUPS Proxy) gdje je logika i stanje razdvojeno u dva ugovora. Time dobivate mogućnost zamjene logike bez gubitka stanja, ali uvodite i dodatnu složenost i vektore napada, pa je ključno pažljivo upravljati admin pravima.
Kako započeti svoj put kao blockchain developer
Ako želite od nule postati blockchain developer specijaliziran za pametne ugovore na Ethereumu, preporučeni put izgleda otprilike ovako:
1. Učvrstite osnove programiranja (bar jedan statički tipizirani jezik).
2. Naučite osnove Ethereuma, transakcija, gas modela i kriptografije (hash funkcije, ECDSA).
3. Prođite kroz službenu Solidity dokumentaciju i OpenZeppelin primjere.
4. Izgradite vlastiti mali projekt: ERC-20 token, escrow ugovor, jednostavni lending pool.
5. Uključite se u community, čitajte codebase poznatih protokola (Uniswap V2/V3, Aave, MakerDAO).
6. Radite vlastite analize postojećih bugova i hackova; pokušajte razumjeti točan lanac događaja.
Uz to, vrijedi pratiti i edukacija resurse fokusirane na sigurnost i formalne metode (npr. symbolic execution, model checking). Takva znanja vas izdvajaju od klasičnih “copy-paste” developera i otvaraju vrata audit firmama i core timovima većih protokola.
Zaključak
Postati blockchain developer i pisati pametne ugovore na Ethereumu znači preuzeti odgovornost za kod koji direktno upravlja kapitalom korisnika. Prednosti su jasne: radite na otvorenoj, globalnoj infrastrukturi, vaši ugovori mogu biti korišteni i nadograđivani od drugih projekata, a transparentnost koda potiče brzu iteraciju i inovaciju.
S druge strane, suočavate se s ograničenjima EVM-a, skupim pogreškama koje se ne mogu lako ispraviti, sigurnosnim rizicima i često zahtjevnim regulatornim okruženjem. Nije dovoljno poznavati samo Solidity; morate razumjeti arhitekturu protokola, ekonomske poticaje, rizike orakla, nadogradivost i dobar governance.
Ova tema je najrelevantnija za developere koji već imaju iskustva u backend ili full-stack razvoju i žele raditi na decentraliziranim financijama, NFT infrastrukturi ili RWA protokolima, ali i za tehničke foundere koji planiraju pokrenuti vlastiti protokol. Ako ste spremni učiti duboko, razmišljati o sigurnosti na prvom mjestu i prihvatiti da je “ship now, fix later” mentalitet opasan na lancu, razvoj pametnih ugovora na Ethereumu može biti jedno od tehnički najzahtjevnijih, ali i najzanimljivijih područja u današnjem softverskom inženjerstvu.
