Od transakcija prema intentima: zašto se mijenja Web3 UX
U prvim generacijama Web3 aplikacija korisnik je morao razumjeti i ručno potvrditi gotovo svaki tehnički detalj: koji pametni ugovor poziva, kojim redoslijedom, koje parametre šalje i koliki plin plaća. Takav model je transparentan, ali u praksi stvara visoku kognitivnu barijeru i prostor za greške – pogrešan approve, krivi router, previsok slippage ili potpisivanje transakcije koju korisnik zapravo ne razumije.
U zadnjih godinu dana sve je izraženiji zaokret prema tzv. intent‑centričnom modelu. Umjesto da korisnik definira kako će se nešto izvršiti, on deklarativno izražava što želi postići: npr. „zamijeni do 1 ETH u DAI uz maksimalni slippage 0,5% prije 18:00“ ili „rebalansiraj portfelj na 60% stablecoini / 40% ETH u idućih 24 sata“.
Specijalizirana infrastruktura zatim prevodi tu namjeru u konkretne on‑chain korake. Time se sloj specifikacije cilja odvaja od sloja izvršenja, što otvara prostor za optimizaciju, bolje korisničko iskustvo i nove sigurnosne i regulatorne izazove.
Što OMNIINTENT konkretno predlaže?
OMNIINTENT je istraživački rad i arhitekturni prijedlog koji ovaj pristup formalizira i razrađuje. Njegov doprinos nije samo konceptualan, već uključuje tri ključne komponente:
- domensko specifičan jezik za intente (ICL – Intent Constraint Language)
- TEE‑bazirani kompajler koji prevodi intente u transakcije
- optimizator izvršenja koji uzima u obzir stanje lanca i tržišne uvjete
ICL omogućuje da se korisničke namjere opišu na strukturiran, strojno čitljiv način: koje su granice rizika, rokovi, dopuštenja nad sredstvima, prihvatljive rute i slično. Kompajler unutar zaštićenog hardverskog okruženja (TEE – Trusted Execution Environment) pretvara taj opis u niz konkretnih poziva pametnih ugovora, dok optimizator bira najbolju varijantu s obzirom na cijenu plina, likvidnost i druge uvjete.
Ključno je da TEE potpisuje rezultat i veže ga za trenutno stanje lanca (npr. specifičan blok ili skup stanja). Time se smanjuje prostor za napade poput frontrunninga ili replaya, jer transakcija vrijedi samo u kontekstu za koji je kompajlirana.
Razdvajanje slojeva: od specifikacije do izvršenja
Tradicionalni Web3 UX može se pojednostavljeno opisati kao „izravno programiranje transakcija“: korisnik kroz sučelje zapravo ručno konstruira niz poziva pametnim ugovorima. U intent‑centričnom modelu uvodi se jasna arhitekturna podjela:
- Sloj specifikacije (intent) – korisnik definira cilj i ograničenja: što želi postići, koji su limiti cijene, roka, rizika, prava nad sredstvima, te eventualne preference (npr. izbjegavanje određenih protokola).
- Sloj izvršenja (transakcije) – infrastruktura odlučuje kako taj cilj postići: koji DEX koristiti, kojim redoslijedom pozvati ugovore, na kojem L2 izvršiti dio radnji, kako grupirati više korisničkih zahtjeva itd.
Ova podjela omogućuje da se sloj izvršenja neprestano unapređuje (bolji algoritmi rutiranja, nove izvore likvidnosti, pametnije upravljanje plinom) bez da korisnik mora mijenjati svoj način interakcije. Za napredne korisnike i dalje može postojati mogućnost ručnog nadzora ili ograničavanja ruta, ali osnovni UX postaje usporediv s Web2 aplikacijama – korisnik definira cilj, a sustav odrađuje tehničke detalje.
Primjer: zamjena tokena s granularnim ograničenjima
U klasičnom modelu korisnik bi za jednostavnu zamjenu tokena često morao:
- potpisati approve za pametni ugovor DEX‑a
- konfigurirati parametre zamjene (slippage, rok, minimalnu količinu)
- platiti dvije odvojene transakcije (approve + swap)
U intent‑centričnom modelu korisnik bi jednostavno definirao: „zamijeni do 1 ETH u DAI, maksimalni slippage 0,5%, rok 10 minuta, ne koristi protokole X i Y, limitiraj dozvolu povlačenja na 1,1 ETH“. Sustav zatim sam odlučuje hoće li koristiti agregator, jedan ili više DEX‑ova, koji poolovi imaju najbolju likvidnost i kako optimizirati potrošnju plina.
Napredne DeFi orkestracije bez kognitivnog opterećenja
Najveći potencijal intent‑centričnog pristupa vidi se u složenim DeFi scenarijima. Danas višekorakne strategije – poput rebalansa portfelja preko više DEX‑ova, premošćivanja (bridging) između L2‑ova ili korištenja kolateraliziranih pozicija – zahtijevaju niz transakcija koje korisnik mora razumjeti i pojedinačno odobriti.
Uz OMNIINTENT‑u sličnu arhitekturu, ti se koraci mogu promatrati kao jedan objedinjeni graf ovisnosti:
- čvorovi predstavljaju pojedinačne on‑chain radnje (swap, deposit, borrow, bridge)
- bridovi predstavljaju ovisnosti (npr. pozajmica je moguća tek nakon deponiranja kolaterala)
- cijeli graf predstavlja korisnički intent, sa svojim ograničenjima i ciljevima
Optimizator može dio čvorova izvršavati paralelno, dio sekvencijalno, uz stalnu procjenu izvedivosti na temelju aktualnih cijena plina, stanja mempoola i dubine likvidnosti. Ako se tijekom izvršenja uvjeti promijene izvan zadanih okvira (npr. slippage pređe dopuštenu granicu), sustav može odustati ili prilagoditi rutu unutar unaprijed definiranih granica.
Za korisnika to znači da može definirati kompleksnu strategiju na razini „ciljnog stanja portfelja“ ili „željene izloženosti riziku“, bez potrebe da razumije detalje svakog protokola. Kriptografska sigurnost i samostalno posjedovanje ključeva ostaju očuvani, ali kognitivno opterećenje se značajno smanjuje.
Sigurnosne implikacije: TEE, stanje lanca i smanjenje napada
OMNIINTENT predlaže da se ključne faze kompajliranja i optimizacije intenteva odvijaju unutar TEE‑a. TEE je hardverski zaštićeno okruženje koje omogućuje izvršavanje koda na način da čak ni operativni sustav ili administrator ne mogu mijenjati njegove interne podatke.
U ovom kontekstu TEE ima nekoliko funkcija:
- pouzdan kompajler – prevodi intent u konkretne transakcije prema unaprijed specificiranim pravilima
- vezivanje za stanje – generirane transakcije vrijede samo za određeno stanje lanca (npr. specifičan blok), čime se smanjuje mogućnost replay napada
- zaštita od manipulacije – treća strana ne može jednostavno izmijeniti logiku kompajlera bez detektabilnog traga
Ovaj pristup, međutim, otvara i nova pitanja povjerenja: koliko se možemo osloniti na sigurnost hardvera, što ako proizvođač TEE‑a ima sigurnosni propust, te kako korisnik može kriptografski verificirati da je izvršenje doista odgovaralo deklariranom kodu? Zbog toga paralelno nastaju i rješenja temeljena na nultoznanstvenim dokazima (ZK), koja nastoje eliminirati povjerenje u hardver i omogućiti kriptografski dokazivo korektno izvršenje kompajlera.
Regulatorna perspektiva: novi sloj posrednika?
Uvođenje intent sloja ne mijenja samo arhitekturu sustava, već i regulatornu sliku. Ako treća strana tumači i prevodi korisničke intente u transakcije, postavlja se pitanje ulazi li takav entitet u kategoriju „posrednika“ ili „pružatelja kripto‑usluga“ prema važećim propisima.
U europskom kontekstu to se posebno odnosi na:
- MiCA – uredbu koja uređuje izdavatelje i pružatelje usluga povezane s kripto‑imovinom
- PSD3/PSR – nadolazeći okvir za platne usluge i regulaciju plaćanja
Ključna pitanja za dizajn intent infrastrukture uključuju:
- tko kontrolira ključeve – ostaje li korisnik jedini vlasnik i kontrolor privatnih ključeva ili intent sloj na neki način preuzima operativnu kontrolu
- kako se bilježe odluke – postoje li auditni logovi koji pokazuju zašto je optimizator odabrao određenu rutu i može li se naknadno provjeriti da je to bilo u najboljem interesu korisnika
- razina diskrecije – ima li pružatelj usluge prostora za subjektivne odluke (npr. preferiranje određenih protokola) i kako se to transparentno komunicira korisniku
Ovisno o odgovorima, pružatelji intent infrastrukture mogli bi biti tretirani kao regulirani posrednici, s obvezama u pogledu licenciranja, upravljanja rizikom, zaštite potrošača i sprječavanja pranja novca. To znači da će tehnički dizajn (npr. razina decentralizacije, transparentnost algoritama, mogućnost nezavisnog audita) izravno utjecati na regulatorni status ovih sustava.
Implementacijski modeli: off‑chain, on‑chain ili hibrid?
Za developere se otvara praktično pitanje: gdje implementirati logiku interpretacije intenteva?
- Off‑chain usluga – logika se izvršava izvan lanca, npr. u TEE‑u ili kao ZK‑kompajler. Prednosti su fleksibilnost, lakše nadogradnje i manji troškovi plina, ali uz veće zahtjeve za povjerenjem i dokazivošću.
- On‑chain modul – dio logike interpretacije i verifikacije intenteva živi u pametnom ugovoru. To povećava transparentnost, ali i troškove te ograničava kompleksnost algoritama zbog ograničenja virtualnih strojeva.
- Hibridni pristup – složena optimizacija i kompajliranje odvijaju se off‑chain, dok on‑chain modul provjerava minimalni skup uvjeta (npr. poštivanje ograničenja definiranih u intentu) prije prihvaćanja transakcije.
OMNIINTENT se naginje TEE‑temeljenom off‑chain pristupu, ali razvoj ZK‑tehnologija potiče istraživanje modela u kojima se sigurnosna svojstva postižu kriptografijom, a ne povjerenjem u hardver. Dugoročno, vjerojatno će koegzistirati više pristupa, ovisno o zahtjevima pojedinih aplikacija (latencija, trošak, regulatorni okvir).
Standardizacija jezika za intente i interoperabilnost
Da bi intent‑centrični Web3 zaživio izvan pojedinačnih projekata, nužna je standardizacija jezika i formata za izražavanje intenteva. Slično kao što danas postoje standardi za tokene (ERC‑20, ERC‑721) ili poruke (EIP‑712), očekuje se razvoj otvorenih specifikacija za:
- strukturu intenteva (obvezna i opcionalna polja)
- način definiranja ograničenja (slippage, rokovi, dozvole, granularna prava povlačenja sredstava)
- mehanizme potpisivanja i verifikacije
- mapiranje na različite L1, L2 i rollup arhitekture
Bez takvih standarda, svaki protokol ili L2 mogao bi definirati vlastiti, nekompatibilni format, što bi otežalo interoperabilnost i onemogućilo razvoj univerzalnih klijentskih alata. Standardizirani jezik za intente omogućio bi da korisnik ili aplikacija generira jedan intent, a različite infrastrukture se natječu u tome tko će ga bolje i sigurnije izvršiti.
U sljedećoj fazi razvoja Web3‑ja, konkurencija se stoga neće voditi samo oko „najbržeg“ L1 ili „najjeftinijeg“ L2, već i oko najpouzdanijeg, najtransparentnijeg i najinteroperabilnijeg sloja za interpretaciju korisničkih namjera.
Zaključak: od klikanja transakcija do upravljanja namjerama
Intent‑centrični modeli predstavljaju prirodan sljedeći korak u evoluciji Web3 UX‑a. Oni ne negiraju temeljna načela decentralizacije i samostalnog posjedovanja ključeva, ali mijenjaju razinu na kojoj korisnik razmišlja i donosi odluke. Umjesto ručnog sastavljanja transakcija, korisnik upravlja svojim namjerama, ograničenjima i razinom povjerenja u infrastrukturu koja te namjere provodi.
OMNIINTENT pokazuje kako se taj pomak može tehnički uokviriti: kroz domenski jezik za intente, TEE‑bazirani kompajler i optimizator koji generira stanje‑vezane transakcije. Istovremeno, otvara pitanja sigurnosti (TEE vs. ZK), regulatornog statusa intent sloja i potrebe za standardizacijom kako bi interoperabilnost bila održiva.
Za dizajnere protokola i developere to znači da će se u nadolazećim godinama morati baviti ne samo implementacijom pametnih ugovora, već i arhitekturom interpretacije korisničkih namjera. Za korisnike, cilj je jednostavniji, razumljiviji i sigurniji Web3, bliži iskustvu koje danas očekuju od kvalitetnih Web2 aplikacija, ali bez odricanja od ključnih prednosti otvorenih blockchain sustava.
