Dora Milen

Posted on Sep 19

Avalanche za developere: od C-Chain dAppa do L1 mreže

#blockchain #web3 #avalanche #bitcoin

Avalanche je najlakše pogrešno razumeti kao još jedan brži Ethereum kompatibilni blockchain. C-Chain zaista izgleda poznato: Solidity, EVM, JSON-RPC, Foundry, Hardhat i standardni wallet adapteri. Međutim, zanimljiviji deo arhitekture počinje kada aplikaciji više nije dovoljan shared chain.

Tada Avalanche nudi prelazak sa aplikacije na C-Chainu na sopstvenu L1 mrežu sa odvojenim izvršavanjem, validatorima, gas tokenom i pravilima pristupa. To nije automatski bolja arhitektura. To je zamena jednog skupa ograničenja drugim.

Praktično pitanje zato nije samo „da li da koristim Avalanche“, već:

Da li je aplikaciji dovoljan javni EVM chain?
Da li su joj potrebni izolovani resursi i prilagodljiva ekonomija?
Da li tim zaista želi da postane operator blockchain infrastrukture?

Avalanche nije jedan blockchain

Avalanche Mainnet čine Primary Network i Avalanche L1 mreže. Primary Network sadrži tri ugrađena chaina:

C-Chain za EVM smart contracte
P-Chain za validatore, staking i L1 operacije
X-Chain za Avalanche native asset operacije

Za većinu dApp developera C-Chain je početna tačka. Njegov EVM chain ID je 43114, dok Fuji C-Chain testnet koristi 43113. Zvanični RPC endpointi su:

Mainnet: https://api.avax.network/ext/bc/C/rpc
Fuji:    https://api.avax-test.network/ext/bc/C/rpc

C-Chain koristi Coreth, Avalanche implementaciju EVM-a, i izlaže Ethereum kompatibilan JSON-RPC. To znači da frontend ili backend koji već komunicira sa Ethereum mrežama uglavnom mora da promeni samo chain konfiguraciju, RPC URL i način finansiranja gas troškova.

P-Chain nije mesto na kojem se izvršavaju Solidity ugovori. On koordinira validatore, registraciju L1 mreža i druge platform-level operacije. Developeri ga najčešće dodirnu tek kada pokreću sopstveni L1 ili rade sa stakingom.

Važna ispravka za stare tehničke tekstove: X-Chain više ne koristi originalni Avalanche DAG consensus u produkciji. Linearizovan je tokom Cortina nadogradnje 2023. godine, pa danas sva tri chaina Primary Networka koriste Snowman porodicu protokola.

Šta developer dobija na C-Chainu

C-Chain je shared, permissionless EVM okruženje. Aplikacija deli blockspace, validatore i fee market sa drugim aplikacijama, ali zauzvrat dobija već postojeću mrežu, standardne integracije i jednostavniji operativni model.

Za Ethereum developera migracija obično ne zahteva promenu programske paradigme:

Smart contracti ostaju u Solidityju
ABI i event logovi rade na poznat način
Transakcije koriste EIP-1559 stil naknada
eth_call, eth_getLogs i ostali standardni RPC pozivi ostaju dostupni
Postojeći EVM walleti i biblioteke uglavnom mogu da se koriste bez posebnog Avalanche SDK-a

Zbog toga je C-Chain razuman izbor kada je cilj da se proizvod testira, a ne da se odmah dizajnira nova mreža.

Najveća praktična prednost nije neka posebna Solidity funkcija. To je mogućnost da postojeći EVM sistem bude integrisan bez razvoja sopstvenog execution layera i bez održavanja validatorske infrastrukture.

Kada shared EVM prestaje da bude dovoljan

Avalanche L1 je suverena mreža sa sopstvenim validatorskim skupom i jednim ili više blockchainova. Svaki blockchain validira tačno jedna L1 mreža, ali jedna L1 može da validira više blockchainova.

Kod EVM L1 mreža najčešći execution layer je Subnet-EVM. Naziv je ostao iz prethodne Avalanche terminologije, iako aktuelna dokumentacija proizvod uglavnom naziva Avalanche L1.

Subnet-EVM daje poznato EVM okruženje, ali uz mogućnost menjanja parametara koji su na C-Chainu mrežni standard:

Native token koji se koristi za gas
Fee konfiguracija
Genesis alokacije
Pravila za deploy smart contracta
Dozvole za slanje transakcija
Validatorski model
Stateful precompile ugovori
Chain ID i mrežni identitet

To ima smisla kada sama mreža postane deo proizvoda, a ne samo mesto na kojem je proizvod deployovan.

Tipični signali da vredi razmotriti L1 su:

Aplikacija ima predvidivo veliko ili veoma promenljivo opterećenje.
Gas mora da se plaća sopstvenim tokenom.
Potrebni su permissioned validatori ili pravila pristupa na nivou protokola.
Aplikacija ne sme da zavisi od aktivnosti drugih dAppova.
Standardni EVM nije dovoljan i potrebni su posebni precompile ugovori.
Organizacija može da finansira i održava nodes, RPC infrastrukturu i monitoring.

Ako nijedan od ovih razloga nije presudan, C-Chain je obično jednostavniji izbor.

Realan use-case: mreža za partnerski loyalty sistem

Zamislimo loyalty platformu koju koriste trgovci, distributeri i payment procesori. Korisnik dobija bodove kod jednog partnera i troši ih kod drugog, dok kompanije periodično poravnavaju obaveze.

Prva verzija sistema može da radi na C-Chainu:

ERC-20 predstavlja bodove ili settlement jedinice
Smart contract vodi mint, burn i transfer pravila
Backend prati event logove
Administrativne operacije kontroliše multisig
Korisnik ili relayer plaća gas u AVAX-u

Ovaj model je dobar za validaciju proizvoda. Nema validatorske infrastrukture, poseban explorer nije obavezan, a ugovori koriste standardni EVM tooling.

Problemi se pojavljuju kada broj partnera i transakcija poraste:

Kompanije žele da gas plaćaju internim utility tokenom
Samo verifikovani partneri smeju da izvršavaju određene transakcije
Deploy novih ugovora mora da bude ograničen
Neočekivana aktivnost na javnom chainu ne sme da utiče na troškove
Validatori treba da budu raspoređeni između nekoliko poslovnih entiteta

U tom trenutku Avalanche L1 može biti smislen sledeći korak.

L1 može koristiti permissioned Proof-of-Authority validatorski model, sopstveni native token za gas i precompile pravila koja ograničavaju ko sme da šalje transakcije ili deployuje ugovore. To ne pretvara blockchain u klasičnu privatnu bazu podataka. Stanje i izvršavanje su i dalje replikovani između validatora, ali članstvo i protokolska pravila kontroliše sama L1 mreža.

Cena te kontrole je veća odgovornost. Ako tri kompanije kontrolišu sva tri validatora, bezbednosni model je upravo takav, bez obzira na to koliko je Avalanche Primary Network decentralizovan.

Praktičan workflow: prvo C-Chain, zatim L1

Najzdraviji razvojni put obično počinje kao standardan EVM projekat.

1. Izolujte chain-specific delove aplikacije

Contract sloj ne treba da zna RPC URL. Frontend ne treba da hardkoduje chain ID na deset mesta. Backend ne treba da pretpostavlja da je native token uvek ETH.

Centralizujte najmanje:

RPC konfiguraciju
Chain ID
Explorer URL
Native currency metadata
Contract adrese
Confirmation i retry politiku
Podržanu EVM verziju

Tako se C-Chain, Fuji i budući L1 tretiraju kao različita deployment okruženja istog sistema.

2. Eksplicitno postavite Cancun EVM target

Aktuelna Avalanche dokumentacija navodi da C-Chain i Subnet-EVM podržavaju Cancun, ali ne i novije EVM hard forkove poput Pectre. Ovo je posebno važno sa Solidityjem 0.8.30 i novijim verzijama, jer compiler može podrazumevano da cilja noviji EVM.

Minimalni foundry.toml može da izgleda ovako:

[profile.default]
evm_version = "cancun"

[rpc_endpoints]
fuji = "https://api.avax-test.network/ext/bc/C/rpc"
avalanche = "https://api.avax.network/ext/bc/C/rpc"

Ovo nije samo podešavanje za testove. Pogrešan EVM target može da proizvede bytecode sa opcodeovima koje ciljna mreža još ne podržava.

3. Deployujte na Fuji

Ako projekat već ima Foundry deployment skriptu, promena mreže svodi se na izbor RPC konfiguracije i naloga sa testnim AVAX-om.

Za jednostavan contract:

forge create src/Settlement.sol:Settlement \
    --rpc-url fuji \
    --private-key "$DEPLOYER_PRIVATE_KEY" \
    --broadcast

Privatni ključ treba da dolazi iz privremenog testnog naloga ili odgovarajućeg signing sistema, a ne iz fajla koji se commitovao u repozitorijum.

Pre deploya je korisno proveriti da RPC zaista pokazuje na očekivanu mrežu:

curl -s https://api.avax-test.network/ext/bc/C/rpc \
    -H 'content-type: application/json' \
    --data '{
        "jsonrpc": "2.0",
        "id": 1,
        "method": "eth_chainId",
        "params": []
    }'

Očekivani rezultat za Fuji je heksadecimalni chain ID 0xa869, odnosno decimalni 43113.

4. Testirajte ponašanje sistema, ne samo ugovore

Pre razmatranja sopstvenog L1, prikupite podatke sa realnog prototipa:

Koliko gasa troše ključne operacije
Koliko eventova backend mora da indeksira
Koliko traje end-to-end potvrda u vašem sistemu
Kako se aplikacija ponaša kada RPC kasni ili odbije zahtev
Koje operacije zaista zahtevaju on-chain izvršavanje
Da li je problem u chainu ili u aplikacionoj arhitekturi

L1 neće popraviti neograničene eth_getLogs upite, loše indeksiranje, serijske backend jobove ili ugovore koji nepotrebno upisuju velike količine podataka.

5. Napravite lokalni L1 tek kada imate konkretan zahtev

Avalanche-CLI vodi developera kroz kreiranje Subnet-EVM konfiguracije i izbor validatorskog modela. Minimalni lokalni workflow počinje komandama:

avalanche blockchain create loyalty
avalanche blockchain deploy loyalty

Prva komanda pokreće interaktivni wizard. Za EVM mrežu bira se Subnet-EVM, a za jednostavan lokalni prototip može se izabrati Proof of Authority.

Druga komanda može da podigne lokalnu Avalanche mrežu i deployuje L1. CLI na kraju prikazuje RPC URL, blockchain ID, EVM chain ID i podatke potrebne za povezivanje walleta.

Lokalni deploy je mesto za eksperimentisanje sa:

Genesis alokacijama
Native gas tokenom
Validator managerom
Fee konfiguracijom
Allowlist precompile ugovorima
ICM porukama između chainova

Produkcioni deploy je znatno ozbiljniji projekat. Dokumentacija eksplicitno preporučuje da se dizajn prvo proveri lokalno i na Fuji testnetu.

Koliko košta Avalanche

Odgovor zavisi od toga da li se koristi C-Chain ili sopstveni L1.

Trošak C-Chain aplikacije

Na C-Chainu korisnik plaća gas u AVAX-u. Za EIP-1559 transakciju efektivna cena gasa određena je kao minimum između fee capa i zbira base fee-a i priority fee-a.

U praksi je trošak transakcije:

gasUsed × effectiveGasPrice

Ne postoji pouzdana fiksna cena za „jednu Avalanche transakciju“. Transfer, ERC-20 operacija, kompleksan swap i deploy ugovora troše veoma različite količine gasa. Base fee se takođe menja sa opterećenjem.

C-Chain izlaže metode eth_baseFee i eth_maxPriorityFeePerGas za procenu parametara transakcije. Dokumentacija navodi minimalni base fee od jednog wei-ja od Fortuna nadogradnje 8. aprila 2025, bez fiksne gornje granice.

Za aplikacioni budžet zato treba meriti stvarne metode ugovora, a ne koristiti prosečnu cenu transfera kao procenu svih operacija.

Trošak sopstvenog L1

L1 ima najmanje četiri kategorije troška:

Kategorija	Šta se plaća
P-Chain operacije	Kreiranje, konverzija i upravljanje validatorima
L1 validator fee	Kontinuirana naknada po aktivnom validatoru
Infrastruktura	Validator, RPC, archive, monitoring i backup nodes
Operacije	Upgrade, incident response, ključevi, observability i bezbednost

Aktuelna dokumentacija navodi približno 1.33 AVAX mesečno po L1 validatoru, uz napomenu da je protokolska naknada dinamička i da se spaljuje. Validator ima balans sa kojeg se naknada kontinuirano skida. Ako balans stigne do nule, validator postaje neaktivan dok se ponovo ne finansira.

Pored protokolske naknade postoje infrastrukturni troškovi. Zvanični deployment primer za AWS us-east-1 navodi ilustrativnu procenu od oko USD 651 mesečno za topologiju sa pet c6a.xlarge validatora, archive RPC nodeom, pruned RPC nodeom, monitoring instancom, S3 i KMS resursima. To nije cena Avalanche proizvoda niti univerzalna produkciona preporuka, već procena za jednu konkretnu infrastrukturu.

Stvarni trošak zavisi od:

Broja i veličine validatora
Cloud provajdera i regiona
Količine stanja i RPC saobraćaja
Archive zahteva
Redundanse
Log retention politike
DDoS zaštite
Indeksera i explorera
Relayera za interchain poruke
Dežurstava i operativnog tima

Za većinu timova najveći skriveni trošak nije AVAX naknada, već pouzdano održavanje distribuiranog sistema.

Helicon menja detalje fee i execution modela

Na dan provere dokumentacije, 19. septembra 2026, Helicon je aktivan na Fuji testnetu od 28. jula 2026. Aktivacija na Mainnetu zakazana je za 22. septembar 2026. u 15:00 UTC.

Helicon uvodi Continuous Execution na C-Chainu, gde se consensus i execution razdvajaju kroz queue. Za developere je posebno važna promena obračuna gasa: na mrežama na kojima je Helicon aktivan naplaćeni gas postaje maksimum između stvarno potrošenog gasa i polovine postavljenog gas limita.

Drugim rečima, posle aktivacije ekstremno konzervativan gasLimit više nije bezazlen. Ako transakcija koristi mnogo manje od polovine limita, korisnik može platiti više nego što odgovara stvarnom gasUsed.

Fuji i Mainnet zato mogu imati različito ponašanje tokom perioda između njihovih aktivacija. Integracioni testovi treba da proveravaju receipt, naplaćenu naknadu i RPC semantiku, a ne samo da li je transakcija završena uspešno.

Interoperabilnost nije isto što i jedan shared state

Avalanche Interchain Messaging, odnosno ICM, omogućava razmenu poruka između C-Chaina i Avalanche L1 mreža. Teleporter je contract-level protokol izgrađen iznad ICM-a.

Tipičan tok izgleda ovako:

Contract na izvornom chainu emituje interchain poruku.
Relayer prikuplja potrebne BLS potpise validatora.
Poruka se dostavlja odredišnom chainu.
Odredišni contract verifikuje i obrađuje poruku.

Važan implementation detalj je da Teleporter adresira odredište pomoću Avalanche blockchain ID-a dužine 32 bajta, a ne pomoću EVM chain ID-a.

To je čest izvor grešaka zato što L1 ima oba identifikatora:

EVM chain ID koristi se za potpisivanje EVM transakcija i wallet konfiguraciju
Avalanche blockchain ID koristi se za identifikovanje chaina u ICM komunikaciji

ICM takođe ne znači da chainovi dele sinhrono stanje. Poruka ima lifecycle, relayer i failure modele. Aplikacija mora da razmatra retry, idempotency, kašnjenje i situaciju u kojoj je izvorna transakcija potvrđena, ali poruka još nije obrađena na odredištu.

Za poslovne procese to često znači da interchain operacija treba da bude state machine, a ne jedan boolean processed.

Trade-off koji marketing obično preskoči

Sopstveni L1 daje izolaciju, ali istovremeno fragmentira sistem.

Dobijate kontrolu

Možete definisati:

Ko validira mrežu
Koji token plaća gas
Ko sme da šalje transakcije
Ko sme da deployuje ugovore
Kakva je fee politika
Koji precompile ugovori postoje

Preuzimate odgovornost

Morate rešiti:

Distribuciju i zaštitu administratorskih ključeva
Validator churn i zamenu nodes
Upgrade koordinaciju
RPC skaliranje
Monitoring consensus i execution sloja
Backup i recovery procedure
Interchain relayer dostupnost
Explorer i indexing infrastrukturu
Komunikaciju sa walletima i integratorima

Najvažnije, Avalanche L1 ima sopstveni validatorski skup. Ne treba je predstavljati kao da automatski nasleđuje kompletnu ekonomsku sigurnost Primary Networka. P-Chain koordinira registraciju i interoperabilnost, ali sigurnost izvršavanja L1 mreže zavisi od njenih validatora i pravila upravljanja.

Permissioned PoA mreža sa nekoliko validatora može biti potpuno racionalan izbor za konzorcijum poznatih kompanija. Nije, međutim, ista bezbednosna pretpostavka kao javni permissionless chain.

EVM kompatibilnost ima nekoliko oštrih ivica

Za standardne JavaScript i TypeScript integracije C-Chain se uglavnom ponaša kao očekivani EVM chain. Ipak, kompatibilnost ne znači da je implementacija identična go-ethereum klijentu.

Jedan specifičan primer odnosi se na Go sisteme koji preuzmu C-Chain blok i zatim lokalno pozovu block.Hash() iz standardnog go-ethereum paketa. C-Chain header sadrži dodatni ExtDataHash, pa standardni klijent može izračunati drugačiji hash od onog koji je mreža vratila. Zvanična dokumentacija zbog toga preporučuje Avalanche prilagođeni ethclient kada Go aplikacija lokalno računa block hash.

Ako aplikacija samo čita JSON-RPC odgovore, logove i receipts bez ponovnog računanja block hasha, ovaj problem se uglavnom ne pojavljuje.

Druga oštra ivica je oslanjanje na široke eth_getLogs upite. Public RPC može biti dovoljan za prototip, ali produkcioni indexer treba da koristi ograničene block range upite, checkpointing i sopstvenu retry politiku. Pokretanje L1 mreže ne uklanja potrebu za dobro dizajniranim data pipelineom.

Kako izabrati između C-Chaina i L1 mreže

Odluka se može svesti na nekoliko pitanja:

Zahtev	C-Chain	Avalanche L1
Standardni Solidity dApp	Dobar izbor	Verovatno nepotrebno
Postojeća javna likvidnost	Prednost	Zahteva interchain integraciju
Sopstveni gas token	Ne	Da
Izolovano opterećenje	Ne	Da
Permissioned validatori	Ne	Da
Protocol-level allowlist	Ograničeno aplikacijom	Precompile opcije
Minimalan operativni teret	Da	Ne
Custom execution pravila	Ne	Da

Najčešća greška je pokretanje L1 mreže zato što zvuči skalabilnije, pre nego što postoji workload koji zahteva takvu izolaciju.

Suprotna greška je pokušaj da se svi poslovni zahtevi uguraju u dApp ugovore na shared chainu, iako organizaciji zapravo trebaju sopstvena pravila validacije, gas ekonomija i kontrolisano članstvo.

Dobar kriterijum je granica odgovornosti: ako mrežni parametri postaju deo specifikacije proizvoda, L1 je vredna ozbiljne evaluacije. Ako je blockchain samo settlement i execution backend, C-Chain će često pružiti bolji odnos jednostavnosti i mogućnosti.

Avalanche je zato zanimljiv manje kao „brži EVM“, a više kao put od standardnog Solidity deploymenta do aplikaciono specifične mreže. Taj put je postepen: contract može prvo živeti na Fuji testnetu, zatim na C-Chainu, a tek kasnije na L1 mreži, bez trenutnog napuštanja EVM toolinga.

To smanjuje cenu eksperimenta. Ne uklanja cenu produkcije.

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.

DEV Community