Zamislite pametni ugovor sa jednim veoma jednostavnim pravilom:
Ako u centralnom Londonu danas padne najmanje 10 milimetara kiše, isplati Alis 10.000 dolara.
Novac je već zaključan. Uslov je napisan u kodu. Niko ne mora da odobri zahtev niti da pregovara o isplati.
Postoji samo jedno nezgodno pitanje.
Kako ugovor zna da je kiša pala?
Ne može da pogleda kroz prozor. Ne može da odšeta do meteorološke stanice. I tokom uobičajenog izvršavanja na Ethereumu, ne može jednostavno da otvori internet vezu i pita meteorološki API šta se dogodilo.
Najčudniji deo je to što ovo slepilo nije nedostatak u sistemu. Ono je deo onoga što omogućava sistemu da uopšte funkcioniše.
Slepa mašina
Ethereum nije jedan računar koji pokreće vaš ugovor. Mnoštvo nezavisnih čvorova mora obraditi iste transakcije i doći do identičnog rezultata. Na osnovu istog prethodnog stanja i istih ulaznih transakcija, oni moraju izračunati potpuno isto novo stanje [1].
Sada zamislite da ugovor može da pozove običan web API usred izvršavanja.
Jedan čvor pita u 14:03:01 i dobije odgovor 9,9 mm. Drugi čvor pita sekundu kasnije i dobije 10,1 mm jer je baza meteoroloških podataka u međuvremenu ažurirana. Treći čvor naiđe na mrežni prekid.
Odjednom, identične blokčejn transakcije više nemaju identične ulazne podatke.
Zato se pametni ugovori ne ponašaju kao uobičajene web aplikacije. Ethereum Virtual Machine (EVM) je namerno izolovan od proizvoljnih mrežnih zahteva tokom izvršavanja. Eksterni podaci moraju ući u blokčejn u obliku koji svi čvorovi mogu da vide i oko koga mogu da se saglase.
Tako Ethereum može biti apsolutno siguran u stvari koje se već nalaze u njegovom svetu — stanje računa, potpise, skladište ugovora, prenose tokena — dok sam po sebi ne zna apsolutno ništa o kiši napolju.
Neko mora da unese činjenicu unutra
Tu na scenu stupaju orakli (oracles) [1].
U najjednostavnijem slučaju, sistem van blokčejna (off-chain) mogao bi da pročita meteorološki izvor, potpiše vrednost kao što je 12,4 mm i pošalje tu vrednost ugovorima. Napredniji orakularni sistemi mogu kombinovati više izveštača, izvora podataka, potpisa, tržišnih opservacija ili mehanizama za osporavanje.
Ali osnovni problem je uvek isti: nešto što se nalazi van blokčejna mora postati informacija koju blokčejn može da iskoristi.
Pretpostavimo da ovlašćeni orakl pošalje transakciju:
Količina kiše u Londonu danas: 12,4 mm.
Ethereum može verifikovati digitalni potpis. Može dokazati koji je ključ autorizovao poruku. Može dokazati tačno koja je vrednost poslata i kada je ušla u lanac.
Ono što ne može dokazati samo na osnovu potpisa jeste da je 12,4 mm kiše zaista palo.
Ta razlika je sama suština problema orakla:
Verifikovanje poruke nije isto što i verifikovanje realnosti.
Hakujte ono u šta ugovor veruje
Ovo je izuzetno važno jer pametni ugovori ne moraju imati grešku u kodu da bi proizveli katastrofalan rezultat. Ponekad kod radi tačno ono za šta je dizajniran — ali sa lošim ulaznim podatkom.
Protokol za pozajmljivanje je odličan primer. Zamislite da uložite 150 dolara vrednosti zaloga da biste pozajmili 100 dolara. Ugovor mora stalno da proverava koliko taj zalog vredi. Ako njegova vrednost padne previše, pozicija se može likvidirati.
Sve zavisi od cene.
U oktobru 2021. godine, C.R.E.A.M. Finance je izgubio oko 130 miliona dolara u napadu koji je uključivao mehanizam procene vrednosti zaloga [2]. Napadač je iskoristio ogromne količine privremeno pozajmljenog kapitala i manipulisao vrednošću koja je služila za procenu yUSD zaloga.
Važan detalj nije sama složenost trgovina. Važno je ono što se desilo sledeće.
Sistem za pozajmljivanje je prihvatio naduvanu vrednost zaloga i postupio u skladu sa tim. Iz ugla ugovora, delovalo je da napadač poseduje znatno vredniji zalog nego što je ekonomski bilo opravdano, pa je protokol dozvolio masovno pozajmljivanje u drugim sredstvima.
Ugovor nije zaboravio kako funkcioniše kolateralizacija.
Verovao je broju koji mu je rečen.
Brzi zajmovi (flash loans) mogu učiniti ovakve napade mnogo moćnijima jer omogućavaju napadaču da raspolaže ogromnim kapitalom unutar jedne nedeljive (atomske) transakcije. Ali brzi zajam sam po sebi nije ranjivost orakla. Dublja ranjivost leži u tome što protokol prihvata cenu ili knjigovodstvenu vrednost kojom se može manipulisati dovoljno jeftino.
Kako onda činjenicu učiniti verodostojnom?
Ne postoji jedan dizajn orakla jer ne postoji jedna vrsta spoljne istine.
Cena ETH-a koja se neprekidno menja nije isti problem kao ukupna količina kiše. Cena koja se već formira na samom blokčejnu nije isto što i otkazivanje leta. A zahtev koji može da čeka šest sati na eventualni prigovor veoma se razlikuje od likvidacije kojoj je cena potrebna odmah.
Zato različiti sistemi proizvode prihvatljive dokaze na različite načine.
Pitajte više glasnika — Chainlink
Umesto da veruje jednom izveštaču, decentralizovana mreža orakla može kombinovati izveštaje sa više nezavisnih čvorova i iz više izvora podataka.
Chainlink-ova arhitektura Offchain Reporting omogućava čvorovima da razmenjuju i agregiraju opservacije van lanca, a zatim pošalju na lanac jedan izveštaj podržan kvorumom [3].
Ideja je jednostavna: jedan loš server, jedan pokvaren API ili jedan nepošten izveštač ne bi trebalo sami da odlučuju o odgovoru.
To ne čini podatak magično istinitim. To menja posao napadača. Korumptirati jedan izvor je mnogo lakše nego korumptirati dovoljno nezavisnih delova sistema izveštavanja da bi lažna vrednost delovala legitimno.
Pratite samo tržište — Uniswap TWAP
Ponekad blokčejnu uopšte nije potreban spoljni glasnik.
Uniswap v2 i v3 mogu podržavati vremenski ponderisane prosečne cene (TWAP), izvedene iz cena dobijenih kroz trgovinsku aktivnost koja se već dešava na samom lancu [4].
Umesto da pita: "Koliko ETH vredi upravo sada?", protokol može pitati nešto bliže ovome:
"Koju je cenu ovo tržište prikazivalo tokom poslednjih nekoliko minuta?"
To je važno jer kratkotrajno guranje plitkog tržišta do apsurdne cene može biti moguće. Ali održavanje te distorzije tokom dužeg vremenskog prozora obično je znatno skuplje i izlaže napadača rizikuju od arbitraže i troškova kapitala.
TWAP ne eliminiše manipulaciju. On čini da napad zavisi od likvidnosti, vremena, strukture tržišta i načina na koji ugovor koristi rezultat.
Donesite svež dokaz samo kada vam zatreba — Pyth
Drugo pitanje nije ko je proizveo cenu, već kada bi blokčejn trebalo da plati da je primi.
Neki orakularni sistemi neprekidno šalju ažuriranja na lanac. To drži podatke spremnim za ugovore, ali česta ažuriranja koštaju gas bez obzira da li neko koristi tu vrednost ili ne.
Pyth je koristan jer podržava i pull obrazac [5]. Sveža potpisana ažuriranja cena mogu postojati van lanca sve dok aplikaciji ne zatrebaju. Korisnik ili aplikacija zatim nose to ažuriranje unutar transakcije, a ugovor ga verifikuje pre upotrebe.
Umesto da stalno ažurira svaku moguću cenu, aplikacija efektivno kaža:
"Treba mi sveža cena sada. Evo potpisanog dokaza."
Pyth takođe podržava i push modele, pa je prava razlika arhitektonska: da li bi podaci trebalo neprekidno da žive na lancu, ili da stignu samo kada su izvršenju zaista potrebni?
Pretpostavite da je tačno dok niko ne prigovori — UMA
Zatim postoji i divno drugačiji pristup: ne pokušavajte da dokažete svaki zahtev unapred.
UMA-in Optimistički Oracle omogućava da neko predloži odgovor i iza njega stavi ekonomsku zalogu. Sledi prozor za osporavanje. Ako niko ne ospori tvrdnju, sistem je prihvata. Ako je neko ospori, pitanje eskalira u UMA-in proces rešavanja sporova [6].
To ima smisla za činjenice kojima nisu potrebna ažuriranja u milisekundama i koje bi bilo teško kodirati kao stalni cenovnik.
Logika je skoro društvena:
Prihvatićemo ovu tvrdnju osim ako neko nije spreman da rizikuje novac tvrdeći da je pogrešna.
Većina bezbednosti orakla svodi se na promenu cene laži
Pogledajte ove dizajne i uočićete obrazac.
Nijedan od njih ne otvara magični prozor kroz koji blokčejn može direktno da pregleda realnost.
Umesto toga, oni čine lažnu informaciju težom, sporijom, rizičnijom ili skupljom za prihvatanje.
Decentralizovani izvor može zahtevati potkupljivanje više nezavisnih izveštača. TWAP može primorati napadača da održava iskrivljeno tržište tokom vremena. Optimistički orakl može učiniti lažnu tvrdnju ranjivom na osporavanje i gubitak uloga.
Kriptografski potpisi dodaju još jedan sloj: oni mogu učiniti izuzetno teškim lažiranje toga ko je šta rekao.
Inženjerski problem stoga najčešće nije:
Kako da laganje učinimo nemogućim?
Već:
Kako da prihvaćenu laž učinimo težom za proizvodnju od vrednosti koju donosi?
Čak i savršenoj kriptografiji i dalje treba prozor
Tu problem postaje još neobičniji.
Moderna kriptografija može dokazati zadivljujuće stvari. Dokaz može potvrditi da je računanje izvedeno tačno, da je određeni ključ potpisao neke podatke, da je vrednost bila uključena u verifikovani skup podataka ili da privatni ulaz zadovoljava javni uslov.
Ali pretpostavimo da senzor za kišu potpiše poruku:
Količina kiše: 10,2 mm.
Kriptografija može dokazati da je ključ senzora zaista potpisao tu poruku i da je niko kasnije nije izmenila.
Ona vam i dalje ne može reći da li je senzor bio pravilno kalibrisan, da li je neko sipao vodu preko njega, ili se zapravo nalazio u Londonu.
Dokaz može učiniti digitalni dokaz izuzetno verodostojnim.
Ali neka opservacija i dalje mora povezati taj dokaz sa svetom.
Ugovor i dalje ne može da pogleda napolje
To je deo koji ostaje skriven iza fraza kao što je kod je zakon.
Pametni ugovor može učiniti posledice prihvaćene činjenice krutima. Kada sistem prihvati 12,4 mm kiše, isplata može biti automatska, deterministička i izuzetno teška za ometanje.
Ali kod ne stvara činjenicu.
Neko je nešto izmerio. Tržište je proizvelo cenu. Izveštači su potpisali opservacije. Trgovci su stvorili prosek. Predlagač je objavio tvrdnju i niko joj nije prigovorio.
Orakl je mašinerija koja jedan od tih procesa pretvara u nešto na osnovu čega je blokčejn spreman da deluje.
A to znači da najdublje pitanje o oraklu zapravo nije:
Kako kod na blokčejnu dobija spoljne podatke?
Već:
Zašto bi mu blokčejn verovao?
Ugovor može dokazati ko je poslao broj.
I dalje ne može da pogleda napolje i vidi da li pada kiša.

Comments 0
Log in to join the conversation.
Log inStart the conversation.