Polygon POL iz ugla developera: EVM, gas i finalnost

Polygon je dovoljno dugo prisutan da njegovo ime često znači nekoliko različitih stvari. Za jednog developera to može biti EVM mreža sa chain ID-em 137. Za drugog je to skup alata za pokretanje sopstvenog lanca. Za trećeg je most prema Ethereumu, a za korisnika token koji je nekada u walletu bio prikazan kao MATIC.

Zato je korisno početi preciznom definicijom:

POL je nativni token Polygon Chain mreže, ranije poznate kao Polygon PoS. Koristi se za gas i staking, a zamenio je MATIC u odnosu 1:1. Polygon Chain je zasebna EVM-kompatibilna mreža sa sopstvenim validatorima, blokovima i mehanizmom finalnosti, čije se kontrolne tačke objavljuju na Ethereumu.

Za developera je važnije šta iz toga sledi nego sam rebranding. Solidity ugovor ne moraš ponovo da osmišljavaš, ali moraš pravilno da modeluješ gas, finalnost, RPC infrastrukturu, indeksiranje događaja i operacije koje prelaze granicu između Polygon Chain mreže i Ethereuma.

POL nije samo novi simbol za MATIC

Na Polygon Chain mreži prelazak sa MATIC-a na POL obavljen je automatski. Balansi nisu zahtevali ručnu migraciju, mada su wallet aplikacije i konfiguracije mreže morale da promene simbol nativne valute iz MATIC u POL.

Za MATIC koji se nalazi na Ethereumu migracija je drugačija. Koristi se migracioni ugovor, a konverzija je 1:1. Stakeri i delegatori nisu morali ručno da migriraju svoj ulog.

U praksi treba proveriti sledeće:

• konfiguracije mreže treba da prikazuju POL, ne MATIC
• tekst u interfejsu, dokumentaciji i obaveštenjima o gasu treba ažurirati
• treasury i monitoring sistemi ne treba da tretiraju POL i MATIC kao dva nezavisna nativna sredstva na Polygon Chain mreži
• ugovori i servisi koji očekuju MATIC sa bridge-a moraju biti provereni
• token liste i price feed konfiguracije ne treba menjati samo na osnovu simbola

Poslednja stavka je posebno važna. Simbol tokena nije identitet tokena. Identitet je kombinacija mreže i adrese ugovora, dok nativni POL na Polygon Chain mreži uopšte nije ERC-20 ugovor.

POL na Ethereumu jeste ERC-20 token i podržava EIP-2612 dozvole zasnovane na potpisu. Nativni POL na Polygon Chain mreži koristi se kao ETH na Ethereumu: plaća gas i šalje se kao nativna vrednost transakcije.

Ako aplikacija ima generički model sredstava, razlika treba da bude eksplicitna:

type Asset =
    | {
          kind: 'native'
          chainId: number
          symbol: string
      }
    | {
          kind: 'erc20'
          chainId: number
          address: `0x${string}`
          symbol: string
      }

Model u kojem se svaki asset identifikuje samo simbolom pre ili kasnije dovodi do pogrešnog balansa, pogrešnog odobrenja ili slanja tokena na neodgovarajuću mrežu.

Kako Polygon Chain zapravo radi

Polygon Chain ima dva glavna softverska sloja:

• Bor je izvršni sloj zasnovan na Go Ethereum kodu. Izvršava EVM transakcije i proizvodi blokove.
• Heimdall-v2 je konsenzusni i koordinacioni sloj zasnovan na Cosmos SDK-u i CometBFT-u. Prati staking na Ethereumu, koordinira validatore, finalizuje segmente Bor lanca i šalje kontrolne tačke na Ethereum.

To znači da aplikacija komunicira sa Polygon Chain mrežom preko standardnog Ethereum JSON-RPC interfejsa. Alati kao što su Foundry, Hardhat, viem i ethers mogu se koristiti bez posebnog Polygon programskog modela.

Ipak, EVM kompatibilnost ne znači da je operativno ponašanje identično Ethereum mainnetu.

Polygon Chain ima sopstveni raspored blokova, validatore, gas tržište i finalnost. Checkpoint na Ethereumu takođe nije isto što i finalnost transakcije unutar Polygon Chain mreže.

Heimdall-v2 koristi milestones kako bi obezbedio determinističku finalnost na samom Polygon lancu. Prema aktuelnoj dokumentaciji, milestone obično finalizuje transakciju za približno 2 do 5 sekundi. Checkpointi koji se naknadno šalju na Ethereum služe za dodatno sidrenje stanja i za procese kao što je dokazivanje burn operacije prilikom povlačenja sredstava.

Ovo daje tri različita stanja koja backend treba da razlikuje:

1. transakcija je poslata, ali još nema receipt
2. transakcija je uključena u blok
3. blok transakcije je finalizovan milestone-om

Mnoge integracije stanu na drugom koraku. To je često dovoljno za optimistički UI, ali nije uvek dovoljno za nepovratnu isporuku robe, izdavanje kupona, knjiženje novca ili pokretanje off-chain procesa koji se ne može vratiti.

Kada Polygon ima smisla

Polygon Chain je praktičan kada aplikacija generiše mnogo transakcija čija je pojedinačna vrednost relativno mala.

Tipični primeri su:

• programi nagrađivanja i lojalnosti
• onchain članstva i pristupne dozvole
• evidencija izdavanja i iskorišćavanja digitalnih prava
• igre sa čestim promenama stanja
• marketplace poravnanja
• stablecoin plaćanja
• dokaz o izvršenoj akciji između više organizacija
• NFT ili ERC-1155 imovina koja se često izdaje i prenosi

Ključni razlog nije samo niži gas. Važna je kombinacija EVM kompatibilnosti, brze finalnosti i postojeće infrastrukture za wallete, RPC pristup i indeksiranje.

To ne znači da svaki događaj treba zapisati u blokčejn. Ako je jedna baza podataka jedini autoritet, svi učesnici veruju istom operatoru i podaci nikada ne izlaze iz jedne aplikacije, PostgreSQL je obično jednostavniji izbor.

Polygon postaje zanimljiv kada više strana treba da deli stanje bez jednog vlasnika baze ili kada korisnik treba da zadrži sredstvo i van originalne aplikacije.

Realan use-case: program lojalnosti više partnera

Zamisli program lojalnosti u kojem restorani, prodavnice i organizatori događaja izdaju zajedničke kredite. Korisnik može dobiti kredit kod jednog partnera, a iskoristiti ga kod drugog.

Klasična implementacija zahteva centralni servis koji:

• vodi saldo svakog korisnika
• određuje ko sme da izdaje kredite
• rešava dvostruko iskorišćavanje
• obračunava dugovanja između partnera
• pruža audit log svim učesnicima

Onchain implementacija ne uklanja poslovna pravila, ali može da obezbedi zajednički izvor istine za izdavanje i iskorišćavanje kredita.

Jedan razuman dizajn mogao bi da izgleda ovako:

1. Partnerov backend proverava kupovinu ili drugu kvalifikovanu akciju.
2. Backend generiše EIP-712 potpisani voucher sa korisnikom, iznosom, kampanjom, nonce vrednošću i rokom važenja.
3. Korisnik ili relayer šalje voucher ugovoru.
4. Ugovor proverava potpis, ulogu izdavaoca, rok i nonce.
5. Stanje se ažurira i emituje se događaj.
6. Indekser svakog partnera obrađuje događaj.
7. Nepovratna off-chain isporuka čeka finalizovan blok.

Voucher model smanjuje potrebu da partnerov backend šalje transakciju za svaku akciju. Istovremeno, nonce sprečava ponovno korišćenje istog potpisa.

Potpisani podaci treba da sadrže najmanje:

• chainId
• adresu verifying ugovora
• identifikator kampanje
• adresu korisnika
• količinu
• nonce
• rok važenja

Bez chainId i adrese ugovora potpis može postati upotrebljiv na drugoj mreži ili drugoj instanci ugovora. Bez nonce vrednosti dobijaš replay problem. Bez roka važenja stari voucher može ostati aktivan neograničeno dugo.

POL ne mora biti vidljiv korisniku

Ako korisnik mora prvo da kupi POL kako bi iskoristio nagradu vrednu nekoliko centi, tehnički je sistem decentralizovan, ali je proizvod verovatno loš.

Polygon Chain podržava standardne obrasce za odvajanje potpisnika akcije od platioca gasa:

• meta-transakcije sa relayerom
• ERC-4337 smart accounti
• paymaster koji sponzoriše gas
• aplikacioni wallet sa kontrolisanim pravilima izvršavanja

Kod klasične meta-transakcije korisnik potpisuje poruku, relayer proverava zahtev i šalje standardnu transakciju o svom trošku. Ugovor zatim proverava originalni potpis i izvršava akciju u ime korisnika.

ERC-4337 uvodi UserOperation, bundler, EntryPoint i opcioni paymaster. To pruža više mogućnosti, kao što su sponzorisani gas, grupisanje akcija i pravila specifična za smart account, ali uvodi dodatnu infrastrukturu i složeniji failure model.

Gas sponsorship zato nije besplatan gas. Samo se menja ko drži POL i ko upravlja budžetom.

Backend tada mora da kontroliše:

• maksimalan gas po korisniku ili akciji
• dozvoljene metode i ugovore
• rate limiting
• zaštitu od replay napada
• dnevni i mesečni budžet
• ponašanje kada relayer pošalje transakciju, ali izgubi odgovor
• ponovno slanje i zamenu zaglavljene transakcije

Za program lojalnosti ima smisla sponzorisati claim ili redeem. Nema smisla sponzorisati proizvoljnu transakciju koju korisnik izabere.

Integracija je standardni EVM workflow

Za Polygon mainnet koristi se chain ID 137, dok Amoy testnet koristi 80002. Gas token na obe mreže je POL. Javni RPC endpointi postoje, ali zvanična dokumentacija upozorava da mogu imati ograničenja protoka i saobraćaja.

Razuman razvojni workflow izgleda ovako:

1. Ugovore razvijaš i testiraš lokalno pomoću Anvila ili Hardhat Networka.
2. Integracione testove pokrećeš na Amoy mreži.
3. Frontend proverava aktivni chainId pre potpisivanja.
4. Backend koristi autentifikovani RPC provajder.
5. Kritična čitanja imaju fallback RPC.
6. Transakcija se prvo simulira, zatim potpisuje i šalje.
7. UI prikazuje stanje slanja, uključivanja i finalnosti odvojeno.
8. Indekser obrađuje događaje idempotentno.
9. Nepovratne off-chain akcije čekaju finalizovan blok.

Test POL za Amoy dostupan je preko nezavisnih faucet provajdera. Prema aktuelnoj dokumentaciji, raniji zvanični Polygon Faucet više nije operativan, pa projekat ne treba da ga hardkodira kao jedini deo onboarding procesa.

Receipt nije isto što i finalnost

Standardni Ethereum JSON-RPC tag "finalized" može se koristiti za dobijanje poslednjeg finalizovanog bloka na Polygon Chain mreži.

Sledeća skripta proverava da li je blok određene transakcije već finalizovan. Koristi Amoy, ali je isti obrazac primenljiv na mainnet uz promenu chain konfiguracije i RPC URL-a.

import {
    createPublicClient,
    formatEther,
    http,
} from 'viem'
import { polygonAmoy } from 'viem/chains'

const rpcUrl = process.env.POLYGON_AMOY_RPC_URL

if (!rpcUrl) {
    throw new Error('POLYGON_AMOY_RPC_URL nije podešen')
}

const hash = process.argv[2] as `0x${string}` | undefined

if (!hash) {
    throw new Error('Prosledi transaction hash kao argument')
}

const client = createPublicClient({
    chain: polygonAmoy,
    transport: http(rpcUrl),
})

const receipt = await client.waitForTransactionReceipt({ hash })
const finalizedBlock = await client.getBlock({
    blockTag: 'finalized',
})

if (finalizedBlock.number === null) {
    throw new Error('RPC nije vratio broj finalizovanog bloka')
}

const gasCost = receipt.gasUsed * receipt.effectiveGasPrice
const isFinalized = receipt.blockNumber <= finalizedBlock.number

console.log({
    transactionBlock: receipt.blockNumber.toString(),
    finalizedBlock: finalizedBlock.number.toString(),
    gasCostPOL: formatEther(gasCost),
    isFinalized,
})

Viem izvozi polygonAmoy kroz viem/chains, a njegov Public Client podržava čitanje blokova i čekanje na receipt preko standardnog JSON-RPC transporta.

U produkciji ovu proveru obično ne treba izvršavati samo jednom. Worker može da sačuva transakciju kao included, periodično čita finalizovani blok i tek potom pređe u stanje finalized.

Koliko košta transakcija

Polygon nema fiksnu cenu transakcije.

Stvarni trošak može se izračunati nakon izvršenja:

gasUsed × effectiveGasPrice

Maksimalni iznos koji je pošiljalac spreman da plati približno je ograničen sa:

gasLimit × maxFeePerGas

Rezultat je denominovan u POL. Njegova vrednost u fiat valuti zavisi od tržišne cene POL-a u trenutku obračuna.

Polygon Chain koristi EIP-1559 model sa:

• baseFee
• maxPriorityFeePerGas
• maxFeePerGas

Legacy transakcije su i dalje kompatibilne, ali se preporučuju Type 2 transakcije. Aktuelna dokumentacija navodi i minimalni priority fee od 25 gwei na mainnetu.

Ako wallet ili biblioteka automatski popunjava fee polja, obično nije potrebno ručno unositi vrednosti. Ako backend sam konstruiše transakcije, Polygon Gas Station daje preporuke za safeLow, standard i fast profile.

Mainnet preporuke dostupne su na:

https://gasstation.polygon.technology/v2

Za Amoy se koristi:

https://gasstation.polygon.technology/amoy

Vrednosti ne treba kopirati iz dokumentacije i hardkodirati. Gas Station ih izračunava iz eth_feeHistory podataka poslednjih blokova, pa ih treba čitati neposredno pre slanja transakcije.

Kod ugovorne funkcije cenu je najbolje proceniti na konkretnoj transakciji:

1. pripremi calldata
2. izvrši simulaciju
3. pozovi eth_estimateGas
4. dodaj kontrolisanu rezervu na gas limit
5. preuzmi trenutne fee preporuke
6. postavi maksimalan prihvatljiv trošak
7. pošalji transakciju

Gas sponsorship zahteva dodatni poslovni limit. Ako aplikacija ima milion korisnika, čak i male pojedinačne naknade postaju značajan operativni trošak.

Kako organizovati backend

Pouzdana Polygon integracija ne završava se pozivom writeContract.

Backend najčešće ima najmanje četiri komponente:

• transaction service
• nonce manager
• event indexer
• reconciliation worker

Transaction service

Transaction service simulira zahtev, procenjuje gas, potpisuje i šalje transakciju. Njegov API treba da prima poslovni identifikator, ne samo calldata.

Na primer, zahtev za izdavanje nagrade može imati interni rewardId. Ako klijent ponovi HTTP zahtev zbog timeouta, servis proverava da li za isti rewardId već postoji kreirana ili poslata transakcija.

Nonce manager

Ako jedan treasury ili relayer nalog šalje više paralelnih transakcija, oslanjanje na eth_getTransactionCount neposredno pre svakog slanja nije dovoljno.

Dva procesa mogu pročitati isti nonce i potpisati različite transakcije. Zato nonce treba rezervisati atomskom operacijom, najčešće kroz bazu ili distribuirani lock.

Potrebno je podržati i zamenu transakcije sa istim nonce-om i većim fee parametrima.

Event indexer

Događaje treba identifikovati kombinacijom:

• chainId
• adrese ugovora
• transaction hash-a
• indeksa loga

Transaction hash sam po sebi nije dovoljan jer jedna transakcija može emitovati više događaja istog tipa.

Indexer takođe treba da razlikuje događaj koji je samo primećen od događaja čiji je blok finalizovan.

Reconciliation worker

RPC timeout ne znači da transakcija nije poslata. Proces može da pošalje raw transaction, izgubi mrežni odgovor i pogrešno zaključi da slanje nije uspelo.

Reconciliation worker zato proverava:

• da li transaction hash postoji
• da li je nonce već iskorišćen
• da li je transakcija zamenjena
• da li je receipt uspešan ili reverted
• da li je blok finalizovan
• da li je očekivani događaj emitovan

To je naročito važno kada blockchain transakcija pokreće fakturisanje, izdavanje digitalne robe ili promenu stanja u drugom sistemu.

Most nije običan transfer

Prebacivanje sredstava između Ethereuma i Polygon Chain mreže nije isto što i transfer unutar jednog lanca.

Bridge operacija uključuje najmanje dva različita konsenzusna domena i više stanja:

• inicirana
• potvrđena na izvornom lancu
• dostupna za dokazivanje ili claim
• izvršena na odredišnom lancu
• neuspešna ili zaglavljena

Aplikacija zato ne treba da prikazuje samo pending i completed.

Za povlačenje sa Polygon Chain mreže na Ethereum, checkpointi imaju posebnu ulogu jer obezbeđuju dokaz o burn operaciji. To znači da finalnost na Polygon Chain mreži i spremnost bridge withdrawal operacije nisu ista stvar.

Ako proizvod često pomera likvidnost između mreža, bridge workflow treba tretirati kao zaseban podsistem sa sopstvenim monitoringom i reconciliation logikom.

Glavni trade-offi

Dobijaš EVM kompatibilnost

Postojeći Solidity kod, ABI-ji i većina Ethereum alata mogu se koristiti uz relativno male izmene.

Ali ne treba pretpostaviti da svaka aplikaciona odluka sa Ethereum mainneta ostaje optimalna. Drugačiji gas i brži blokovi mogu opravdati drugačiji batching, indeksiranje i UX.

Dobijaš bržu finalnost

Milestones omogućavaju determinističku finalnost bez čekanja na Ethereum checkpoint.

Ipak, receipt i finalnost treba odvojeno pratiti. Wallet može prikazati potvrdu pre nego što backend transakciju smatra konačnom.

Plaćaš manje po akciji, ali dobijaš više akcija

Niže naknade često menjaju ponašanje proizvoda. Funkcija koja se na Ethereumu poziva jednom mesečno na Polygonu može biti pozivana pri svakoj korisničkoj akciji.

To povećava:

• broj nonce konflikata
• opterećenje RPC-a
• broj događaja za indeksiranje
• trošak relayera
• potrebu za batchingom i rate limitingom

Korisnicima je potreban POL ili sponzor

Ako ne koristiš relayer ili paymaster, korisnik mora imati POL. To je prihvatljivo za DeFi aplikaciju, ali često nije prihvatljivo za consumer proizvod.

Sponzorisanje rešava UX problem, ali treasury tada preuzima promenljiv gas trošak i rizik zloupotrebe.

Bezbednosni model nije Ethereum L1

Polygon Chain ima sopstveni skup validatora i sopstveni konsenzus, dok se checkpoint podaci objavljuju na Ethereumu.

To nije isti model kao direktno izvršavanje na Ethereum L1. Takođe ga ne treba automatski izjednačavati sa rollupom koji stanje dokazuje Ethereumu. Izbor zavisi od vrednosti koja se štiti i posledica eventualnog prekida mreže ili bridge infrastrukture.

Javni RPC nije produkcioni SLA

Javni endpoint je koristan za lokalni razvoj i probne skripte. Za produkciju obično su potrebni autentifikovani provajder, metrike, retry pravila i najmanje jedan fallback.

Retry treba primenjivati pažljivo. Ponoviti eth_call je jednostavno. Ponoviti poslovnu operaciju koja potpisuje novu transakciju bez idempotency ključa nije.

Polygon Chain, CDK i zkEVM nisu ista odluka

Ime Polygon danas obuhvata više slojeva infrastrukture. Izbor Polygon Chain mreže znači da aplikaciju postavljaš na postojeći chain ID 137.

Polygon CDK je druga odluka: koristi se kada želiš sopstveni lanac i spreman si da upravljaš dodatnom infrastrukturom, parametrima i interoperabilnošću.

Polygon zkEVM je ranije bio zasebna javna mreža. Aktuelna Polygon dokumentacija ga označava kao deprecated i ne preporučuje ga za nove integracije. Za nove aplikacije preporučuju se Polygon Chain ili CDK, zavisno od toga da li koristiš postojeću mrežu ili pokrećeš sopstveni lanac.

Zato zahtev „aplikacija treba da radi na Polygonu” nije dovoljno precizan. Tehnička specifikacija treba da sadrži bar:

• naziv mreže
• chain ID
• nativnu valutu
• RPC provajdera
• explorer
• očekivani nivo finalnosti
• bridge koji se koristi
• token adrese po mreži

Praktična odluka

Polygon Chain je dobar kandidat kada aplikaciji treba EVM okruženje za veliki broj relativno jeftinih transakcija, uz finalnost dovoljno brzu za interaktivni proizvod.

Nije automatski najbolji izbor kada:

• sva stanja kontroliše jedan backend
• nema potrebe za prenosivom digitalnom imovinom
• vrednost transakcije zahteva bezbednosni model Ethereum L1
• proizvod ne može operativno da podrži wallet, RPC, indeksiranje i reconciliation
• bridge predstavlja kritičnu tačku koju tim ne može pouzdano da nadgleda

Najkorisniji prvi eksperiment nije izdavanje novog tokena. Bolje je uzeti jednu ograničenu funkciju, kao što je izdavanje potvrde, redeem potpisanog vouchera ili zapisivanje zajedničkog audit događaja, postaviti je na Amoy i izmeriti ceo workflow.

Tada postaju vidljive stvari koje se ne vide iz Solidity koda: koliko traje finalnost, kako wallet reaguje na promenu mreže, kako RPC otkazuje, kako se rešava duplo slanje i koliko zaista košta jedna poslovna operacija.

---

Sponzorstvo

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti, prodati, čuvati i razmenjivati podržane kriptovalute i fiat valute.

Više informacija dostupno je na stranici Volet Srbija.

Za otvaranje naloga možete koristiti Volet.com pozivni link.

Izvori

1. Polygon Developer Docs, POL
2. Polygon Developer Docs, Migrate to POL
3. Polygon Developer Docs, Polygon Chain architecture overview
4. Polygon Developer Docs, Finality
5. Polygon Developer Docs, RPC endpoints
6. Polygon Developer Docs, Estimate gas fees
7. Polygon Developer Docs, EIP-1559
8. Polygon Developer Docs, Meta transactions
9. Polygon Developer Docs, EIP-4337
10. Polygon Developer Docs, Test token faucets
11. Viem Documentation, Public Client
12. Viem Documentation, Chains
13. Volet Srbija