BNB Smart Chain iz ugla EVM developera, bez prečica

BNB Smart Chain nije samo jeftiniji Ethereum

BNB Smart Chain, skraćeno BSC, jeste EVM-kompatibilan Layer 1 blockchain na kojem se transakcije plaćaju tokenom BNB. Pokrenut je 2020. kao Binance Smart Chain, a od februara 2022. nosi sadašnji naziv.

Najkraći odgovor na pitanje zašto bi ga developer koristio glasi: omogućava primenu poznatog Solidity i Ethereum toolchaina na mreži sa kratkim vremenom bloka i relativno jeftinim izvršavanjem transakcija.

To, međutim, ne znači da je BSC kopija Ethereuma sa drugim RPC URL-om. EVM kompatibilnost pokriva veliki deo developer iskustva, ali konsenzus, finalnost, infrastruktura, gas tržište i operativni rizici nisu isti.

BSC mainnet koristi chain ID 56, testnet chain ID 97, a BNB je izvorni token kojim se plaća gas. Većina Ethereum alata, uključujući Foundry, Hardhat, Remix, ethers, viem i web3.js, može da se koristi bez posebnog BSC SDK-a.

Upravo je to najzanimljivija karakteristika mreže: prelazak sa drugog EVM chaina obično ne zahteva novu programsku paradigmu, ali produkciona integracija ipak traži razumevanje onoga što se nalazi ispod EVM interfejsa.

Gde se BSC uklapa u BNB Chain

Terminologija ume da bude zbunjujuća:

• BNB Chain je naziv šireg ekosistema.
• BNB Smart Chain je EVM-kompatibilan Layer 1 unutar tog ekosistema.
• opBNB je Layer 2 mreža izgrađena iznad BSC-a.
• BNB Greenfield je zasebna mreža usmerena na decentralizovano skladištenje podataka.

Stara BNB Beacon Chain ugašena je nakon BNB Chain Fusion procesa tokom 2024. godine. Zato novu arhitekturu ne treba zasnivati na starim tutorijalima koji opisuju dual-chain model između Beacon Chain i BSC mreže.

Za većinu Solidity developera BSC treba posmatrati kao samostalni EVM Layer 1. Ako aplikaciji treba još jeftinije i učestalije izvršavanje, opBNB može biti sledeća opcija, ali tada u sistem ulaze dodatni L2 koncepti kao što su sekvencer, premošćavanje sredstava i L1 finalnost.

Kako BNB Smart Chain radi ispod EVM sloja

BSC koristi Parlia konsenzus, varijantu Proof of Staked Authority modela. Validator se ne bira samo na osnovu identiteta ili operativne dozvole, već i prema delegiranom BNB ulogu.

Prema aktuelnoj dokumentaciji, mreža ima 45 aktivnih validatora: 21 validator u Cabinet grupi i 24 kandidata. Za konkretnu epohu bira se skup od 21 konsenzus validatora, sastavljen od 18 Cabinet validatora i tri kandidata. Validator koji ne učestvuje u produkciji blokova ili prekrši konsenzusna pravila može biti kažnjen slashing mehanizmom.

Ovo proizvodi drugačiji bezbednosni profil od Ethereum Proof of Stake sistema. Manji aktivni skup validatora omogućava kraće intervale između blokova i bržu koordinaciju, ali predstavlja kompromis u pogledu decentralizacije i otpornosti na koordinisani uticaj.

Fermi nadogradnja aktivirana je na mainnetu 14. januara 2026. i smanjila je ciljani interval bloka na približno 0.45 sekundi. BSC koristi i Fast Finality mehanizam, pri kojem blok u uobičajenim uslovima postaje finalan nakon glasova potrebne većine validatora, tipično u okviru dva naredna bloka.

Za frontend to znači brzu povratnu informaciju. Za backend koji pomera sredstva, izdaje robu ili zaključava stanje, novi blok ipak ne treba automatski tretirati kao neopoziv.

BSC JSON-RPC podržava finalized oznaku bloka. Umesto oslanjanja na proizvoljan broj potvrda, servis može eksplicitno pročitati poslednji finalizovani blok:

curl -s "$BSC_RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "method": "eth_getBlockByNumber",
    "params": ["finalized", false],
    "id": 1
  }'

Pre upotrebe treba proveriti da izabrani RPC provider podržava ovaj tag i kako dokumentuje BSC finalnost. Aplikacija može prikazati transakciju kao primljenu čim dobije receipt, ali poslovno nepovratnu akciju izvršiti tek kada blok transakcije više nije noviji od finalizovanog bloka.

Šta EVM kompatibilnost stvarno donosi

BSC je zasnovan na fork-u go-ethereum klijenta i nastoji da zadrži kompatibilnost sa Geth JSON-RPC API-jima.

To u praksi znači da se zadržavaju poznati elementi:

• Solidity i Vyper ugovori
• ABI kodiranje
• Ethereum adrese i secp256k1 potpisi
• eth_call, eth_estimateGas i eth_sendRawTransaction
• ERC-20, ERC-721 i ERC-1155 interfejsi
• događaji i logovi
• proxy obrasci
• MetaMask i drugi EVM walleti
• Foundry, Hardhat i standardne biblioteke

BEP-20 je naziv koji se na BSC-u tradicionalno koristi za fungibilne tokene. Sa stanovišta savremene implementacije, standardni ERC-20 ugovor i proveren alat poput OpenZeppelin Contracts biblioteke uglavnom su bolja polazna tačka od kopiranja nasumičnog BEP20.sol fajla iz starog tutorijala.

Kompatibilnost ipak nije identitet. BSC ima sopstvene sistemske ugovore, konsenzusne API-je, parametre mreže i ritam nadogradnji. Kod koji zavisi od preciznog ponašanja bloka, gas tržišta, validatora ili specifičnih Ethereum hard forkova mora se posebno testirati.

Posebnu pažnju zaslužuju:

• aplikacije koje koriste block.timestamp kao precizan časovnik
• logika zasnovana na broju blokova
• ugovori koji očekuju određenu vrednost block.basefee
• MEV-osetljive transakcije
• oracle ažuriranja
• cross-chain poruke
• indeksiranje velikog broja događaja

Ako ugovor čuva period od približno jednog dana, izražavanje tog perioda kao fiksnog broja blokova vezuje poslovnu logiku za trenutni interval bloka. Nadogradnje poput Lorentz, Maxwell i Fermi upravo pokazuju da se taj interval može menjati. Za vremenske rokove je obično primereniji block.timestamp, uz standardno upozorenje da ni on nije precizan zidni sat.

Realan use-case: zajednički registar isporuka

Zamislimo marketplace u kojem prodavac, kupac, loyalty servis i osiguravač nisu deo iste organizacije.

Centralna baza može jednostavno voditi statuse porudžbina. Blockchain postaje opravdan tek kada više nezavisnih strana treba da proverava isti zapis bez poverenja u administratora jedne baze.

U tom slučaju nije neophodno odmah praviti on-chain escrow koji čuva novac. Prva korisna iteracija može biti znatno uža:

1. Marketplace kreira neprovidni identifikator porudžbine.
2. Prodavac otvara zapis na BSC-u.
3. Kupac potvrđuje isporuku svojim walletom.
4. Drugi sistemi slušaju događaj DeliveryConfirmed.
5. Loyalty servis izdaje bodove, a osiguravač zatvara pokriće.

Ugovor ne treba da sadrži ime, adresu, broj telefona, opis robe ili interni broj porudžbine. Blockchain nije privatna baza. Umesto toga koristi se nasumično posoljen bytes32 identifikator koji se povezuje sa stvarnim podacima isključivo u kontrolisanom off-chain sistemu.

Minimalna verzija ugovora mogla bi izgledati ovako:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract DeliveryRegistry {
    enum Status {
        None,
        Open,
        Delivered,
        Cancelled
    }

    struct Order {
        address seller;
        address buyer;
        Status status;
    }

    mapping(bytes32 orderId => Order order) public orders;

    error InvalidBuyer();
    error OrderAlreadyExists();
    error OrderNotOpen();
    error Unauthorized();

    event OrderOpened(
        bytes32 indexed orderId,
        address indexed seller,
        address indexed buyer
    );

    event DeliveryConfirmed(bytes32 indexed orderId);
    event OrderCancelled(bytes32 indexed orderId);

    function open(bytes32 orderId, address buyer) external {
        if (buyer == address(0)) revert InvalidBuyer();
        if (orders[orderId].status != Status.None) {
            revert OrderAlreadyExists();
        }

        orders[orderId] = Order({
            seller: msg.sender,
            buyer: buyer,
            status: Status.Open
        });

        emit OrderOpened(orderId, msg.sender, buyer);
    }

    function confirmDelivery(bytes32 orderId) external {
        Order storage order = orders[orderId];

        if (msg.sender != order.buyer) revert Unauthorized();
        if (order.status != Status.Open) revert OrderNotOpen();

        order.status = Status.Delivered;
        emit DeliveryConfirmed(orderId);
    }

    function cancel(bytes32 orderId) external {
        Order storage order = orders[orderId];

        if (msg.sender != order.seller) revert Unauthorized();
        if (order.status != Status.Open) revert OrderNotOpen();

        order.status = Status.Cancelled;
        emit OrderCancelled(orderId);
    }
}

Ovaj ugovor namerno ne čuva sredstva. Time izbegava čitavu klasu problema vezanih za token kompatibilnost, reentrancy, povraćaj sredstava, sporove i administrativne privilegije.

Njegova vrednost nije u tome što blockchain zamenjuje bazu, već što daje mali, zajednički i proverljiv protokol između organizacija.

Produkcijska verzija bi verovatno zahtevala rokove, potpise bez direktne transakcije kupca, poništavanje kompromitovanog walleta i precizniji model sporova. Te funkcije ne treba dodavati pre nego što poslovni proces zaista zahteva njihovu cenu i složenost.

Od lokalnog testa do BSC testneta

Pošto je BSC EVM kompatibilan, lokalni workflow se ne razlikuje mnogo od rada na drugim EVM mrežama:

1. Ugovor se razvija i testira lokalno.
2. Pokreću se unit, fuzz i invariant testovi.
3. Deployment se prvo simulira.
4. Ugovor se objavljuje na BSC testnetu.
5. Izvorni kod se verifikuje na exploreru.
6. Backend i frontend testiraju se protiv stvarnog RPC-ja.
7. Tek zatim se priprema mainnet deployment.

Sa Foundry alatom osnovni projekat može da se napravi komandom:

forge init delivery-registry
cd delivery-registry
forge test

Aktuelni javni testnet endpoint i chain ID mogu se proveriti pre deploymenta:

export BSC_TESTNET_RPC_URL="https://bsc-testnet-dataseed.bnbchain.org"

cast chain-id --rpc-url "$BSC_TESTNET_RPC_URL"

Očekivani rezultat je 97.

Nakon što testnet wallet dobije tBNB sa zvaničnog faucet-a, ugovor može da se objavi pomoću forge create:

forge create src/DeliveryRegistry.sol:DeliveryRegistry \
  --rpc-url "$BSC_TESTNET_RPC_URL" \
  --private-key "$DEPLOYER_PRIVATE_KEY" \
  --broadcast \
  --legacy

Foundry podržava deployment preko forge create, dok je za složenije sisteme sa više ugovora praktičniji forge script.

Opcija --legacy eksplicitno koristi legacy format transakcije. BSC podržava EIP-1559 strukture, ali njegov protokol ne primenjuje Ethereum model obavezne promenljive osnovne naknade. U BSC klijentu je base fee postavljen na nulu, pa legacy transakcije ostaju praktičan i kompatibilan izbor za deployment alate.

Privatni ključ u promenljivoj okruženja prihvatljiv je samo kao skraćeni primer. Produkcijski deployment treba da koristi odvojen deployer nalog, hardverski signer ili kontrolisani secrets sistem. Nalog koji objavljuje ugovor ne mora kasnije imati administrativna prava nad njim.

Frontend i wallet integracija

Za browser aplikaciju integracija izgleda kao kod drugih EVM mreža. Aplikacija treba da proveri:

• da li postoji wallet provider
• da li je povezan odgovarajući nalog
• da li je aktivan chain ID 56 ili 97
• da li korisnik ima dovoljno BNB za gas
• da li je simulacija poziva uspešna
• da li je receipt uspešan
• da li je odgovarajući blok finalizovan

Ne treba pretpostaviti da je mreža ispravna samo zato što wallet vraća adresu. Potpis validne transakcije za pogrešan chain može dovesti do konfuznog korisničkog iskustva, pogotovo ako je isti ugovor objavljen na više mreža.

Adrese deploymenta treba verzionisati zajedno sa ABI-jem:

{
  "56": {
    "DeliveryRegistry": "0x..."
  },
  "97": {
    "DeliveryRegistry": "0x..."
  }
}

Chain ID mora biti deo ključa konfiguracije. Jedna globalna promenljiva CONTRACT_ADDRESS brzo postaje izvor grešaka kada projekat dobije testnet, staging, mainnet ili multichain deployment.

Za write operacije dobar frontend workflow je:

1. Pročitaj trenutno stanje.
2. Simuliraj poziv.
3. Zatraži potpis.
4. Prikaži hash transakcije.
5. Sačekaj receipt.
6. Proveri status.
7. Sačekaj finalnost ako sledeća radnja ima poslovnu vrednost.
8. Osveži stanje iz chaina, umesto da trajno veruješ lokalnoj pretpostavci.

Greška nakon slanja transakcije ne znači nužno da transakcija nije poslata. Browser može izgubiti konekciju nakon što RPC prihvati potpisanu transakciju. Zato je hash transakcije važniji od lokalnog statusa Promise objekta.

Backend i indeksiranje događaja

Najveća razlika između demo aplikacije i produkcionog sistema često nije smart contract, već indeksiranje.

Javni BSC RPC endpointi imaju ograničenja. Zvanična dokumentacija navodi zbirni limit od 10.000 zahteva u pet minuta za navedene javne mainnet i testnet endpoint-e. Na navedenim javnim mainnet endpoint-ima eth_getLogs može biti onemogućen, uz preporuku da se za učestalo praćenje logova koristi odgovarajući provider ili WebSocket infrastruktura.

To znači da produkcijski backend ne treba graditi oko beskonačnog ponavljanja upita:

eth_getLogs(fromBlock = 0, toBlock = latest)

Pouzdaniji indexer čuva najmanje:

• poslednji obrađeni blok
• hash poslednjeg obrađenog bloka
• transakcioni hash
• indeks loga
• adresu ugovora
• verziju ABI-ja
• status finalnosti
• sirove argumente događaja

Jedinstveni ključ događaja obično se formira od transactionHash i logIndex. Potrošač mora biti idempotentan, jer reconnect ili ponovno indeksiranje može isporučiti isti događaj više puta.

Praktičan model ima dve faze:

• observed: događaj je pronađen u novom bloku
• finalized: blok događaja dostigao je finalnost

Frontend može odmah prikazati observed stanje kao privremeno. Servis koji izdaje nagradu, šalje robu ili pokreće nepovratnu integraciju treba da čeka finalized.

Za manji projekat dovoljan je upravljani RPC sa WebSocket podrškom i PostgreSQL worker. Za veći sistem treba razmotriti namenski indexer, sopstveni node ili servis koji eksplicitno podržava istorijske logove i garantuje potrebni retention.

Koliko košta korišćenje BNB Smart Chain mreže

BSC nema fiksnu cenu za deployment ili poziv funkcije. Trošak transakcije određuju dve vrednosti:

trošak u BNB = potrošeni gas × efektivna cena gasa

Broj gas jedinica zavisi od izvršenih EVM operacija. Upis nove vrednosti u storage obično je skuplji od čitanja, emitovanje događaja ima cenu, a deployment mora platiti izvršenje konstruktora i čuvanje bytecode-a.

Cena gasa zavisi od mreže i prioriteta transakcije. Ne treba je hardkodovati na osnovu blog posta ili vrednosti primećene prethodne nedelje. RPC metoda eth_gasPrice može vratiti trenutnu preporuku providera:

curl -s "$BSC_RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "method": "eth_gasPrice",
    "params": [],
    "id": 1
  }'

Pre slanja write poziva aplikacija treba da koristi eth_estimateGas ili odgovarajuću metodu biblioteke. Nakon izvršenja, stvarni trošak može se dobiti iz gasUsed i effectiveGasPrice polja transaction receipt-a.

Cena izražena u USD nije protokolarna konstanta. Ona zavisi i od tržišne vrednosti BNB u trenutku transakcije. Za budžetiranje je zato korisnije pratiti:

• gas po konkretnoj funkciji
• trenutnu cenu gasa
• dnevni broj transakcija
• BNB potrošnju po danu
• odvojenu konverziju BNB u USD

Ako aplikacija subvencioniše korisničke transakcije, trošak nije samo gas. U računicu ulaze relayer infrastruktura, zaštita od zloupotrebe, upravljanje nonce vrednostima, monitoring i punjenje operativnih walleta.

Gde se najčešće kriju problemi

Brz blok nije isto što i finalizovana poslovna odluka

Receipt potvrđuje da je transakcija izvršena u određenom bloku. Ne govori sam po sebi da aplikacija treba odmah da preduzme nepovratnu off-chain akciju.

Model finalnosti mora biti deo domenske logike, a ne samo blockchain helper funkcija.

Niska cena podstiče nepotrebne upise

Kada je storage jeftiniji, lako je svaki klik pretvoriti u transakciju. To obično pogoršava UX, komplikuje migracije i javno objavljuje podatke koji su mogli ostati van chaina.

Bolji obrazac je da se na chain stave vlasništvo, autorizacija, konačni obračun i dokazi, a pretraga, analitika i prolazno aplikativno stanje ostave off-chain.

EVM kompatibilnost ne eliminiše testiranje po mreži

Fork test na Ethereum stanju ne dokazuje da će deployment, finalnost, oracle, RPC provider i gas strategija raditi na BSC-u.

Testnet nije potpuna simulacija mainneta, ali otkriva pogrešan chain ID, wallet konfiguraciju, probleme sa transaction type-om, explorer verifikacijom i indeksiranjem.

Javni RPC nije produkcioni SLA

Besplatan endpoint je odličan za proveru konekcije i razvoj. Nije zamena za ugovoreni kapacitet, redundantne providere ili sopstvenu infrastrukturu kada aplikacija zavisi od dostupnosti chain podataka.

RPC sloj treba posmatrati kao distribuiranu zavisnost. Uvedite timeout, retry sa backoff-om, circuit breaker i proveru da različiti provideri vraćaju kompatibilnu visinu lanca.

Privatnost se ne dobija heširanjem predvidivih podataka

Hash email adrese ili broja porudžbine nije anoniman ako napadač može pogoditi originalnu vrednost i ponoviti hash.

Za on-chain identifikatore koristite dovoljno nasumičan salt, domensko razdvajanje i jasnu politiku toga ko čuva mapiranje između internog zapisa i bytes32 identifikatora.

Jeftinija greška je i dalje greška

Niži gas ne umanjuje posledice pogrešne kontrole pristupa, kompromitovanog admin ključa ili nebezbednog upgrade proxy-ja.

BSC ugovor treba tretirati kao ugovor na bilo kom javnom EVM chainu: testovi, statička analiza, pregled privilegija, verifikovan source, monitoring i nezavisna revizija u skladu sa vrednošću koju kontroliše.

Kada BSC ima smisla

BNB Smart Chain je racionalan izbor kada projekat ima nekoliko sledećih osobina:

• tim već poznaje Solidity i EVM alate
• ciljna publika već koristi BNB ili BSC wallete
• transakcije moraju biti dovoljno jeftine za učestaliju upotrebu
• potreban je brz interaktivni UX
• aplikacija se oslanja na postojeće EVM ugovore i biblioteke
• prihvatljiv je PoSA bezbednosni i decentralizacioni model
• projekat može da obezbedi pouzdano indeksiranje i RPC infrastrukturu

Manje je privlačan ako aplikacija zahteva bezbednosni model sa veoma velikim skupom validatora, ako korisnici nemaju razlog da drže BNB za gas ili ako sistem uopšte nema više nezavisnih strana kojima treba zajedničko stanje.

Ako samo jedan backend ima pravo da piše podatke, a svi korisnici mu već veruju, PostgreSQL je verovatno jednostavniji, privatniji i jeftiniji sistem.

Produkcijski workflow koji ne zavisi od sreće

Razuman put do mainneta izgleda ovako:

1. Definišite koji deo sistema zaista mora biti on-chain.
2. Napravite ugovor bez čuvanja sredstava ako use-case to dozvoljava.
3. Napišite unit, fuzz i invariant testove.
4. Testirajte kontrole pristupa i sve terminalne state transitions.
5. Pokrenite lokalni deployment i simulirajte neuspele pozive.
6. Objavite ugovor na BSC testnetu.
7. Verifikujte source i compiler konfiguraciju.
8. Testirajte wallet promenu mreže i pogrešan chain ID.
9. Izmerite gas za realne scenarije, ne samo za happy path.
10. Implementirajte idempotentni event indexer.
11. Razdvojte observed i finalized stanje.
12. Uvedite najmanje dva RPC providera za kritične servise.
13. Dokumentujte admin ključeve, mogućnost nadogradnje i proceduru incidenta.
14. Objavite mainnet deployment sa odvojenim deployer nalogom.
15. Nadgledajte događaje, neuspele transakcije, saldo operativnih walleta i zaostajanje indexera.

BSC je najlakše razumeti kao pragmatičan EVM Layer 1 sa agresivno optimizovanim vremenom bloka. Njegova prednost nije nova programska paradigma, već mogućnost da postojeći EVM način rada primenite u drugačijem odnosu cene, latencije i decentralizacije.

To ga čini dobrim kandidatom za eksperiment, naročito kada se počne malim ugovorom koji rešava jasno ograničen problem. Najvažniji deo tog eksperimenta nije deployment, već provera da li aplikacija pravilno obrađuje finalnost, indekse, troškove, privatnost i kvarove infrastrukture.

---

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. BNB Chain, “BSC Is Now BNB Chain” i definicija BNB Smart Chain naziva: bnbchain.org/en/blog/bsc-is-now-bnb-chain-the-infrastructure-for-the-metafi-universe
2. BNB Chain dokumentacija, “Wallet Configuration” i “Quick Guide”: docs.bnbchain.org/bnb-smart-chain/developers/wallet-configuration i docs.bnbchain.org/bnb-smart-chain/developers/quick-guide
3. BNB Chain, “BNB Chain Fusion”: bnbchain.org/en/bnb-chain-fusion
4. BNB Chain dokumentacija, “BSC Validator Overview”: docs.bnbchain.org/bnb-smart-chain/validator/overview
5. BNB Chain dokumentacija, “Fermi Upgrade of BSC” i “Introduction”: docs.bnbchain.org/announce/fermi-bsc i docs.bnbchain.org/bnb-smart-chain/introduction
6. BNB Chain dokumentacija, “JSON-RPC Endpoint”: docs.bnbchain.org/bnb-smart-chain/developers/json_rpc/json-rpc-endpoint
7. Foundry dokumentacija, “Deploying and Verifying”: getfoundry.sh/forge/deploying
8. BNB Chain BSC source, obračun efektivne cene gasa i nulta osnovna naknada: github.com/bnb-chain/bsc/blob/master/core/types/transaction.go i github.com/bnb-chain/bsc/blob/master/params/protocol_params.go
9. Volet Srbija