DEV Community: Dora Milen

USDT i USDC u praksi: stablecoin izbor za developere

Dora Milen — Sat, 19 Sep 2026 16:53:56 +0000

USDT i USDC se često svode na istu rečenicu: tokeni čija bi vrednost trebalo da prati američki dolar. Za developera je to nedovoljno precizno.

Oba stablecoina predstavljaju programabilnu vrednost koja može da se šalje preko javnih blockchain mreža, koristi u smart contractima i uključi u automatizovane finansijske tokove. Ipak, razlikuju se po izdavaču, sastavu rezervi, dostupnim mrežama, načinu direktnog otkupa, cross-chain infrastrukturi i pojedinim detaljima smart contract implementacije.

Te razlike postaju važne kada aplikacija prestane da bude prototip. Pogrešna pretpostavka o token adresi, mreži ili varijanti tokena može da proizvede veći problem od pogrešno izabranog API endpointa. Blockchain transakcija uglavnom ne može da se opozove, a oznaka USDC ili USDT u korisničkom interfejsu ne govori dovoljno o tome koji se asset zaista prenosi.

Dokumentacija i uslovi navedeni u članku provereni su 19. septembra 2026.

Šta je USDT

USDT, često pisan i kao USD₮, jeste stablecoin koji izdaje Tether. Ideja je da jedan USDT predstavlja vrednost jednog američkog dolara i da se može kupiti ili otkupiti u odnosu jedan prema jedan, u skladu sa uslovima izdavača i uz primenljive naknade.

USDT nije samostalan blockchain. To je token izdat na više blockchain mreža. Tether trenutno navodi podršku za mreže i protokole kao što su Ethereum, Tron, Solana, Avalanche, TON, Aptos, Near, Tezos, Polkadot Asset Hub, Liquid i nekoliko EVM kompatibilnih mreža.

Isti simbol zato može da predstavlja različite tehničke objekte:

Na Ethereum mreži USDT je ERC-20 token.
Na Tron mreži je TRC-20 token.
Na Solani je SPL token.
Na TON mreži je Jetton.
Na Aptosu je fungible asset.
Na Polkadot Asset Hubu identifikuje se preko asset ID-ja.

Kada korisnik kaže da želi da pošalje USDT, developer mora da postavi dodatno pitanje: koji USDT i na kojoj mreži?

Tether navodi da su tokeni u opticaju pokriveni rezervama čija je vrednost najmanje jednaka vrednosti izdatih tokena. Prema uslovima izdavača, rezerve mogu da uključuju novac, novčane ekvivalente i druge vrste imovine, uključujući određena potraživanja.

Proces na visokom nivou izgleda ovako:

Verifikovani klijent prenosi fiat sredstva Tetheru.
Tether izdaje odgovarajuću količinu USDT-a na podržanoj mreži.
Tokeni se prenose između adresa i koriste na sekundarnom tržištu.
Pri direktnom otkupu USDT se vraća izdavaču.
Otkupljeni tokeni se povlače iz opticaja ili ostaju u treasury adresama dok ponovo ne budu izdati.

Tether pravi razliku između tokena koji su autorizovani, ali se još nalaze u treasury adresama, i tokena koji su stvarno izdati i nalaze se u opticaju. To je važno kada se on-chain supply pokušava direktno porediti sa tržišnom kapitalizacijom.

Šta je USDC

USDC je stablecoin koji izdaje Circle. Kao i USDT, dizajniran je da predstavlja američki dolar na blockchain mrežama i da bude otkupljiv u odnosu jedan USDC za jedan USD, pod uslovima izdavača.

Circle navodi da je USDC u potpunosti pokriven visokolikvidnim novcem i novčanim ekvivalentima. Većina rezervi drži se kroz Circle Reserve Fund, državni money market fond registrovan u SAD, kojim upravlja BlackRock i koji može sadržati gotovinu, kratkoročne američke trezorske zapise i overnight repo transakcije obezbeđene američkim državnim hartijama. Preostali deo rezervi drži se u gotovini kod finansijskih institucija.

Circle objavljuje podatke o rezervama, mint i burn tokovima, kao i mesečne izveštaje o potvrdi rezervi treće strane.

Tehnički, USDC takođe postoji na većem broju blockchain mreža. Circle je 16. septembra 2026. navodio 38 mreža sa nativnim USDC-em, uključujući Ethereum, Solanu, Base, Arbitrum, Avalanche, Polygon PoS, OP Mainnet, Aptos, Sui, Stellar, Noble, XRPL i druge.

Ovde je ključna reč nativni.

Nativni USDC izdaje Circle na konkretnoj mreži. Bridged USDC nastaje kada nezavisni bridge zaključa token na jednoj mreži i izda njegovu reprezentaciju na drugoj. Takav token može imati simbol USDC, USDC.e ili nešto slično, ali nije nužno isto što i Circle-issued USDC.

Circle eksplicitno upozorava da se bridged USDC ili drugi nepodržani tokeni ne šalju na Circle Mint adrese, jer sredstva možda neće biti automatski prepoznata ili vraćena.

USDC mint i redemption workflow izgleda slično kao kod USDT-a:

Institucionalni klijent šalje USD kroz podržani bankarski kanal.
Circle izdaje odgovarajući broj USDC tokena.
USDC se prenosi na javnoj mreži ili koristi u smart contractima.
Pri otkupu tokeni se vraćaju Circleu.
USDC se spaljuje, a fiat sredstva šalju na registrovani bankovni račun.

Circle Mint je namenjen institucijama, a ne individualnim korisnicima i malim kompanijama. Manji sistemi obično dolaze do USDC-a preko berzi, payment providera, custodiana ili drugih on-ramp servisa.

Stablecoin nije isto što i dolar na bankovnom računu

USDT i USDC pokušavaju da prate vrednost dolara, ali nisu depoziti na korisnikovom bankovnom računu. Holder poseduje blockchain token i oslanja se na kombinaciju:

rezervi izdavača,
ugovornog prava na otkup,
operativne sposobnosti izdavača,
bankarskih partnera,
blockchain mreže,
smart contract implementacije,
tržišne likvidnosti.

Cena na sekundarnom tržištu zato može privremeno da odstupi od jednog USD. Izdavač može nuditi direktan otkup po nominalnoj vrednosti, ali to ne znači da će svaka berza, DEX ili OTC desk u svakom trenutku ponuditi istu cenu.

Postoji i administrativni sloj. USDT i USDC nisu decentralizovani u smislu da nijedna strana nema kontrolu nad token ugovorom. Oba izdavača zadržavaju mogućnost blokiranja određenih adresa ili zamrzavanja tokena u okolnostima definisanim njihovim uslovima, uključujući pravne i compliance zahteve.

Za payment aplikaciju to nije skriven detalj. To je deo operativnog modela.

Zašto bi developer koristio stablecoin

Najbolji razlog nije spekulacija, već settlement.

Stablecoin omogućava da aplikacija prenosi vrednost:

bez čekanja na radno vreme banke,
preko jedinstvenog programabilnog interfejsa,
između walleta, smart contracta i custodial sistema,
uz javno proverljiv status transakcije,
bez izlaganja korisnika volatilnosti tipičnoj za BTC ili ETH,
kroz automatizovane treasury i payout procese.

Realan use-case može biti platforma koja naplaćuje usluge međunarodnim klijentima i isplaćuje izvođače u različitim državama.

Klijent može platiti USDC na Base mreži, dok izvođač traži USDT na Tronu. Platforma tada mora da reši više problema od običnog transfer poziva:

Generisanje ili dodeljivanje deposit adrese.
Prepoznavanje tačnog token ugovora.
Praćenje blockchain događaja.
Čekanje odgovarajućeg broja potvrda.
Knjiženje u internom ledgeru.
Konverziju između asseta ili mreža, ako je potrebna.
Finansiranje gas walleta.
Kreiranje i slanje payout transakcije.
Reconciliation između internog stanja, blockchaina i custodiana.
Upravljanje compliance i operativnim rizicima.

Sam token transfer je najkraći deo sistema.

Kako se USDT i USDC integrišu

Postoje tri uobičajena nivoa integracije.

Direktna on-chain integracija

Aplikacija komunicira sa token ugovorom preko RPC noda. Za EVM mreže to obično znači rad sa funkcijama:

balanceOf
transfer
approve
allowance
transferFrom

Aplikacija sama upravlja privatnim ključevima, gasom, nonce vrednostima, potvrdom transakcija i indeksiranjem događaja.

Prednost je puna kontrola nad funds flow logikom. Mana je to što tim preuzima odgovornost za wallet bezbednost i blockchain infrastrukturu.

Custodial ili wallet infrastruktura

Provider upravlja ključevima ili pruža MPC, policy engine, transaction signing i webhookove. Aplikacija radi preko API-ja umesto direktnog potpisivanja svake transakcije.

Ovaj model smanjuje količinu blockchain koda u aplikaciji, ali uvodi novog dobavljača, njegov pricing model, ograničenja i operativni rizik.

Integracija sa izdavačem ili on-ramp providerom

Institucionalni sistemi mogu direktno integrisati mint i redemption tokove, dok manje aplikacije obično koriste berzu, payment processor ili on-ramp.

Ovo je potreban sloj kada sistem mora da prelazi između bankovnog novca i stablecoina. Smart contract sam po sebi ne može da pošalje bankarski transfer.

Nemoj identifikovati token samo simbolom

USDT i USDC nisu dovoljni identifikatori.

Minimalni identitet tokena treba da uključuje:

blockchain namespace + chain ID + token address ili asset ID

Za EVM mreže model može izgledati ovako:

{
  "asset": "USDC",
  "network": "base",
  "chainId": 8453,
  "contract": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "variant": "native"
}

Circle navodi ovu adresu kao nativni USDC contract na Base mreži.

Produkcioni token registry treba da bude eksplicitna allowlista. Ne treba automatski prihvatiti token samo zato što njegov contract vraća symbol() == "USDC". Bilo ko može da deployuje token sa tim simbolom.

Isto važi za ime, logo i broj decimala. To su metapodaci, ne dokaz identiteta.

Registry obično treba da čuva:

interni asset ID,
mrežu i chain ID,
contract adresu ili asset ID,
očekivani broj decimala,
status depozita i povlačenja,
minimalni iznos,
potrebne potvrde,
oznaku native, bridged ili wrapped,
datum poslednje provere prema dokumentaciji izdavača.

Podrška za mreže se menja. Tether je, na primer, prestao da izdaje i bude obavezan da otkupljuje USDT na pojedinim starijim mrežama, uključujući Omni, Algorand i EOS/Vaulta. Hardkodovana lista bez procesa ažuriranja vremenom postaje rizik.

USDT ima važan ERC-20 detalj

Ethereum USDT ugovor zasnovan je na starijoj implementaciji koja u transfer funkciji ne vraća standardnu Boolean vrednost. Tether to eksplicitno navodi u integration smernicama i preporučuje korišćenje SafeERC20 biblioteke.

Ako smart contract očekuje da svaki ERC-20 token strogo prati moderni interfejs, integracija može da se ponaša neočekivano.

Kratak primer ugovora koji prihvata unapred odobrene stablecoine:

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

import {IERC20} from
    "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import {SafeERC20} from
    "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

contract StablecoinCheckout {
    using SafeERC20 for IERC20;

    address public immutable merchant;

    mapping(address token => bool supported) public supportedTokens;
    mapping(bytes32 invoiceId => bool settled) public settledInvoices;

    event PaymentReceived(
        bytes32 indexed invoiceId,
        address indexed payer,
        address indexed token,
        uint256 amount
    );

    constructor(address merchant_, address[] memory tokens) {
        require(merchant_ != address(0), "invalid merchant");
        merchant = merchant_;

        for (uint256 i = 0; i < tokens.length; i++) {
            supportedTokens[tokens[i]] = true;
        }
    }

    function pay(
        bytes32 invoiceId,
        address token,
        uint256 amount
    ) external {
        require(supportedTokens[token], "unsupported token");
        require(!settledInvoices[invoiceId], "invoice settled");
        require(amount > 0, "zero amount");

        settledInvoices[invoiceId] = true;

        IERC20(token).safeTransferFrom(
            msg.sender,
            merchant,
            amount
        );

        emit PaymentReceived(
            invoiceId,
            msg.sender,
            token,
            amount
        );
    }
}

Ovo nije kompletan checkout sistem. Nedostaju autorizovano kreiranje faktura, očekivani token i iznos, rok važenja, refund logika, pause mehanizam i administracija allowliste.

Primer pokazuje dve bitne stvari:

tokeni se prihvataju preko contract adresa, ne preko simbola,
transfer koristi SafeERC20, koji podržava i tokene bez standardne povratne vrednosti.

Deposit workflow je više od slušanja `Transfer` događaja

Najjednostavniji deposit servis prati Transfer događaje za poznati token contract i traži transfere ka adresama platforme. To je početak, ali nije dovoljan produkcioni dizajn.

Pouzdan workflow izgleda približno ovako:

Indekser detektuje kandidata za uplatu.
Proverava chainId i contract adresu.
Čuva transaction hash, log index i block number.
Čeka definisan nivo finalnosti.
Ponovo proverava receipt i canonical block hash.
U jednoj atomskoj operaciji upisuje depozit i ledger stavku.
Emituje interni događaj DepositCredited.
Periodični reconciliation proverava stanje na blockchainu.

Kombinacija transactionHash + logIndex može da služi kao idempotency ključ za EVM događaje. Transaction hash sam nije dovoljan jer jedna transakcija može emitovati više transfer događaja.

Sistem treba da razlikuje najmanje sledeća stanja:

detected -> confirming -> confirmed -> credited
                      \-> reorged
                      \-> rejected

Broj potvrda ne treba univerzalno hardkodovati za sve mreže. Ethereum, L2 rollup, Solana i Tron nemaju isti model finalnosti niti isti profil rizika.

Iznose čuvaj kao cele brojeve

Stablecoin iznos ne treba čuvati kao floating-point broj.

Umesto:

10.25 USDC

ledger treba da čuva:

10250000 base units

ako konkretan token koristi šest decimala.

Broj decimala ne treba slepo pretpostaviti za svaki token na svakoj mreži. Može se pročitati iz ugovora tokom procesa registracije asseta, proveriti prema zvaničnoj dokumentaciji i zatim čuvati u token registryju.

U finansijskom ledgeru korisno je čuvati:

asset_id,
amount_base_units,
direction,
account_id,
reference_type,
reference_id,
status,
created_at.

Blockchain balance nije zamena za interni ledger. Jedna on-chain adresa može držati zbir sredstava velikog broja korisnika, dok poslovni sistem i dalje mora da zna kome pripada koji deo.

Cross-chain nije običan transfer

USDC na Ethereumu i USDC na Base mreži nisu isti smart contract. Činjenica da oba predstavljaju USDC ne znači da token može direktno biti poslat sa jedne mreže na drugu.

Za nativni USDC Circle nudi Cross-Chain Transfer Protocol, odnosno CCTP. On koristi burn-and-mint model:

USDC se spaljuje na izvornoj mreži.
Circleov attestation servis potvrđuje događaj.
Potvrda se prosleđuje odredišnoj mreži.
Isti iznos nativnog USDC-a mintuje se na odredištu.

CCTP zato ne zavisi od klasičnog bridge liquidity poola. I dalje postoje mrežne naknade, podržani parovi mreža, potvrde, vreme čekanja i protokolarni uslovi koje integracija mora da obradi.

Za USDT ne postoji direktan ekvivalent CCTP-u namenjen opštoj developerskoj integraciji. Prelazak između mreža u praksi se obično obavlja preko berze, custodiana, liquidity providera ili bridge sistema. Svaka od tih opcija uvodi svoj counterparty i smart contract rizik.

Ako aplikacija ne mora sama da obavlja cross-chain konverziju, često je jednostavnije da korisniku jasno prikaže podržane kombinacije:

USDC on Base
USDC on Ethereum
USDT on Tron
USDT on Ethereum

To je preciznije od jednog generičkog dugmeta „Deposit USDC“.

Koliko košta integracija

Ne postoji jedna cena USDT ili USDC integracije. Trošak se sastoji od više slojeva.

Blockchain naknade

Svaki on-chain transfer zahteva mrežnu naknadu. Na EVM mrežama plaća se native gas tokenom, čak i kada se prenosi USDT ili USDC.

Wallet sa 100.000 USDC i nula native gas tokena ne može da pošalje standardnu transakciju. Treasury servis zato mora odvojeno da prati:

stablecoin balance,
gas balance,
minimalni gas threshold,
gas top-up transakcije.

Cena se menja u zavisnosti od mreže i opterećenja, pa je ne treba hardkodovati u poslovnu logiku.

Infrastruktura

Direktna integracija može da uključuje troškove:

RPC providera,
arhivskih ili dedicated nodova,
blockchain indexera,
wallet ili MPC providera,
chain analytics sistema,
monitoring i alerting infrastrukture,
eksternih bezbednosnih provera.

Ovi troškovi često postanu veći od samog gasa.

Konverzija na sekundarnom tržištu

Ako se USDT kupuje za USDC ili stablecoin prodaje za fiat, pojavljuju se:

trading fee,
spread,
slippage,
withdrawal fee,
bankarska naknada.

Ti troškovi dolaze od izabrane berze ili liquidity providera, ne iz samog ERC-20 standarda.

Direktan rad sa Tetherom

Prema Tetherovom cenovniku proverenom u septembru 2026, minimalni iznos za direktnu kupovinu ili otkup iznosi 100.000 USD. Naknada za otkup je veći iznos od 1.000 USD ili 0,1%, naknada za kupovinu je 0,1%, a verifikacija naloga košta 150 USD u Tether tokenima.

To direktan issuer workflow čini prvenstveno institucionalnim mehanizmom. Većina manjih aplikacija USDT nabavlja i prodaje preko sekundarnog tržišta.

Direktan rad sa Circleom

Circle Mint takođe je institucionalni proizvod. Circle navodi da za USD wire tokenizaciju Circle i njegovi bankarski partneri ne naplaćuju naknadu ako je transfer denominovan u USD, mada korisnikova banka može naplatiti svoj deo.

Outbound on-chain transferi naplaćuju se prema stvarnom mrežnom trošku. Redemption pricing od 15. marta 2026. zavisi od izabranog Circle Mint nivoa, dnevnog obima i mesečne neto mint ili redemption aktivnosti. Određeni nivoi imaju osnovne naknade i dodatne pragove za veliki neto redemption.

Zbog toga „USDC redemption je besplatan“ više nije dovoljno precizan opis za svaki institucionalni scenario. Konkretna cena zavisi od Circle Mint ugovora, nivoa i tokova klijenta.

USDT vs USDC: ključne razlike

Oblast	USDT	USDC
Izdavač	Tether	Circle
Osnovni model	Fiat-backed stablecoin	Fiat-backed stablecoin
Rezerve	Novac, novčani ekvivalenti i druga imovina prema objavama izdavača	Visokolikvidan novac i novčani ekvivalenti, većinom kroz Circle Reserve Fund
Direktan pristup izdavaču	Institucionalan, uz minimum i eksplicitne naknade	Circle Mint, namenjen institucijama
Blockchain podrška	Snažno prisustvo na mrežama kao što su Tron, Ethereum, Solana i TON	Veliki broj nativno podržanih mreža, uključujući više EVM i non-EVM ekosistema
Zvanični cross-chain mehanizam	Nema opšti developerski ekvivalent CCTP-u	CCTP burn-and-mint za podržane mreže
EVM integracioni detalj	Ethereum contract ima stariji `transfer` bez standardnog Boolean povratnog rezultata	Standardniji ERC-20 interfejs, uz specifične Circle ekstenzije i administrativne kontrole
Bridged varijante	Potrebna pažljiva provera izvora i bridge modela	Jasna razlika između native USDC i bridged varijanti kao što je `USDC.e`
Administrativna kontrola	Izdavač može blokirati adrese i zamrznuti tokene	Izdavač koristi blocklist mehanizam i može ograničiti transfere
Tipičan razlog za izbor	Kontrapartneri, berze ili payout tržišta već koriste USDT na konkretnoj mreži	Nativni multichain deployment, CCTP ili direktniji institucionalni fiat workflow

Prednosti i mane USDT-a

Prednosti

Široka praktična prihvaćenost

USDT je često već deo treasury i settlement procesa berzi, OTC deskova, walleta i međunarodnih kontrapartnera. Ako primalac eksplicitno traži USDT na Tronu ili TON-u, izbor drugog stablecoina može samo prebaciti trošak konverzije na njega.

Dostupnost na različitim tipovima mreža

USDT nije ograničen na EVM ekosistem. To omogućava integraciju sa mrežama koje imaju različite troškove, finalnost i wallet infrastrukturu.

Jednostavan osnovni token model

Na podržanoj mreži USDT se uglavnom integriše kao standardni fungible token, uz poznate specifičnosti pojedinih ugovora.

Mane

Nepotpuno standardna Ethereum implementacija

Smart contract kod koji pretpostavlja strogo standardan ERC-20 povratni rezultat može imati problem sa Ethereum USDT-om. SafeERC20 ili ekvivalentna proverena biblioteka praktično je obavezna.

Visok prag za direktan issuer workflow

Minimum od 100.000 USD i redemption fee čine direktan rad sa izdavačem nepraktičnim za male tokove.

Nema jedinstvenog developerskog cross-chain protokola poput CCTP-a

Platforma mora sama da izabere bridge, exchange ili custodian workflow za prebacivanje USDT likvidnosti između mreža.

Promene u podršci mrežama

Tether je prestao da izdaje ili otkupljuje tokene na pojedinim legacy mrežama. Integracija zato zahteva održavan token registry i periodičnu proveru zvanične podrške.

Prednosti i mane USDC-a

Prednosti

Jasno dokumentovane nativne implementacije

Circle održava listu contract adresa i podržanih mreža. To olakšava izgradnju pouzdane allowliste.

CCTP za nativni cross-chain USDC

Burn-and-mint model smanjuje zavisnost od bridge liquidity poolova i izbegava kreiranje dodatne wrapped reprezentacije za podržane transfere.

Transparentno opisan model rezervi

Circle javno opisuje sastav rezervi, objavljuje podatke o rezervama i obezbeđuje mesečne potvrde treće strane.

Široka podrška nativnog USDC-a

Veliki broj EVM i non-EVM mreža omogućava da se isti poslovni asset koristi kroz više tehničkih okruženja, bez nužnog oslanjanja na nezavisne wrapped tokene.

Mane

Native i bridged USDC lako se mogu pomešati

Korisnički interfejsi često prikazuju isti ili sličan simbol za tehnički različite assete. Pogrešna varijanta može ostati zaglavljena u deposit workflowu.

Circle Mint nije proizvod za svakog developera

Direktan fiat mint i redemption zahteva odgovarajući institucionalni nalog. Mala aplikacija i dalje mora da izabere eksternog on-ramp providera.

Pricing direktnog redemptiona nije jedna fiksna cifra

Cena zavisi od Circle Mint nivoa i obima. Finansijski model mora uzeti u obzir konkretan ugovor, a ne samo mrežni gas.

Centralizovane administrativne kontrole

Kao i USDT, USDC ima issuer-level mogućnost blokiranja adresa i ograničavanja tokena.

Kako izabrati između USDT-a i USDC-a

Izbor ne treba početi pitanjem „koji stablecoin je bolji“, već pitanjem „koji settlement tok pokušavamo da izgradimo“.

Izaberi prema primaocu

Ako payout korisnici gotovo uvek traže USDT na Tronu, USDC na Ethereumu ne rešava isti problem. Uveo bi dodatnu konverziju, gas i operativni korak.

Ako poslovni partneri koriste Circle Mint, nativni USDC i bankarske tokove, USDC može biti prirodniji izbor.

Izaberi mrežu pre biblioteke

Chain izbor određuje:

trošak transakcije,
brzinu i finalnost,
wallet podršku,
RPC i indexing infrastrukturu,
likvidnost,
on-ramp i off-ramp dostupnost,
dostupnost tokena za gas.

Tek posle toga ima smisla birati SDK ili wallet provider.

Proveri izlaz pre ulaza

Jedna od skupljih arhitektonskih grešaka jeste izgraditi jednostavan deposit flow, a tek kasnije proveriti kako će kompanija prodati stablecoin za fiat ili ga isplatiti korisnicima.

Pre implementacije proveri:

ko može izvršiti redemption,
koji su minimalni iznosi,
koje bankarske države i valute su podržane,
koliko traje settlement,
kako se obračunavaju naknade,
šta se dešava tokom bankarskog vikenda ili praznika,
šta se dešava ako je asset ili adresa blokirana.

Ne moraš podržati oba

Podrška za dva stablecoina na četiri mreže nije jedna funkcionalnost. To je najmanje osam kombinacija asseta i mreže, sa zasebnim contract adresama, gas modelima, confirmation pravilima, hot walletima i reconciliation procesima.

Razuman prvi deployment često podržava:

jedan stablecoin,
jednu mrežu,
jedan custody model,
jedan fiat izlaz.

Drugi asset treba dodati kada postoji merljiva potreba korisnika ili partnera, ne zato što je još jedan ERC-20 poziv jednostavan.

Produkciona checklista

Pre uključivanja stvarnih sredstava proveri sledeće:

Token se identifikuje preko mreže i contract adrese.
Contract adrese dolaze iz dokumentacije izdavača.
Native, bridged i wrapped varijante imaju različite interne asset ID-jeve.
Iznosi se čuvaju kao integer base units.
Deposit obrada je idempotentna.
Sistem obrađuje reorg i neuspešne transakcije.
Confirmation policy je definisan po mreži.
Wallet servis prati stablecoin i gas balance.
Withdrawal se prvo simulira kada infrastruktura to podržava.
Privatni ključevi nisu u aplikacionoj bazi ili .env fajlu produkcionog servera.
Postoje transaction i dnevni withdrawal limiti.
Velike transakcije zahtevaju dodatnu autorizaciju.
Interni ledger ne zavisi od trenutnog blockchain balansa.
Reconciliation se izvršava nezavisno od webhookova.
Postoji procedura za pogrešnu mrežu ili pogrešan token.
Issuer i provider naknade nisu hardkodovane.
Dokumentacija o podržanim mrežama periodično se ponovo proverava.
Postoji plan za pause depozita i povlačenja po assetu i mreži.

Zaključak

USDT i USDC rešavaju sličan problem, ali nisu međusobno zamenljivi na nivou implementacije.

USDT je često praktičan kada postojeći kontrapartneri i payout tržišta već rade sa njim na određenoj mreži. USDC nudi širi skup dokumentovanih nativnih implementacija i CCTP kao standardizovan cross-chain put za podržane mreže. USDT na Ethereumu zahteva pažnju zbog starije ERC-20 implementacije, dok kod USDC-a posebnu pažnju treba posvetiti razlici između native i bridged tokena.

Najvažnija odluka ipak nije naziv stablecoina. To je kombinacija izdavača, mreže, contract adrese, custody modela i fiat izlaza.

Dobar prototip može da pošalje token. Dobra produkciona integracija zna koji je token poslat, kada je transakcija konačna, kome sredstva pripadaju, koliko transfer zaista košta i kako će se vrednost na kraju vratiti u bankarski sistem.

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

Polygon POL iz ugla developera: EVM, gas i finalnost

Dora Milen — Sat, 19 Sep 2026 00:23:30 +0000

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:

transakcija je poslata, ali još nema receipt
transakcija je uključena u blok
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:

Partnerov backend proverava kupovinu ili drugu kvalifikovanu akciju.
Backend generiše EIP-712 potpisani voucher sa korisnikom, iznosom, kampanjom, nonce vrednošću i rokom važenja.
Korisnik ili relayer šalje voucher ugovoru.
Ugovor proverava potpis, ulogu izdavaoca, rok i nonce.
Stanje se ažurira i emituje se događaj.
Indekser svakog partnera obrađuje događaj.
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:

Ugovore razvijaš i testiraš lokalno pomoću Anvila ili Hardhat Networka.
Integracione testove pokrećeš na Amoy mreži.
Frontend proverava aktivni chainId pre potpisivanja.
Backend koristi autentifikovani RPC provajder.
Kritična čitanja imaju fallback RPC.
Transakcija se prvo simulira, zatim potpisuje i šalje.
UI prikazuje stanje slanja, uključivanja i finalnosti odvojeno.
Indekser obrađuje događaje idempotentno.
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:

pripremi calldata
izvrši simulaciju
pozovi eth_estimateGas
dodaj kontrolisanu rezervu na gas limit
preuzmi trenutne fee preporuke
postavi maksimalan prihvatljiv trošak
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

Polygon Developer Docs, POL
Polygon Developer Docs, Migrate to POL
Polygon Developer Docs, Polygon Chain architecture overview
Polygon Developer Docs, Finality
Polygon Developer Docs, RPC endpoints
Polygon Developer Docs, Estimate gas fees
Polygon Developer Docs, EIP-1559
Polygon Developer Docs, Meta transactions
Polygon Developer Docs, EIP-4337
Polygon Developer Docs, Test token faucets
Viem Documentation, Public Client
Viem Documentation, Chains
Volet Srbija

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

Dora Milen — Sat, 19 Sep 2026 00:03:45 +0000

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.

Izvori

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

Dora Milen — Fri, 18 Sep 2026 23:36:23 +0000

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:

Marketplace kreira neprovidni identifikator porudžbine.
Prodavac otvara zapis na BSC-u.
Kupac potvrđuje isporuku svojim walletom.
Drugi sistemi slušaju događaj DeliveryConfirmed.
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:

Ugovor se razvija i testira lokalno.
Pokreću se unit, fuzz i invariant testovi.
Deployment se prvo simulira.
Ugovor se objavljuje na BSC testnetu.
Izvorni kod se verifikuje na exploreru.
Backend i frontend testiraju se protiv stvarnog RPC-ja.
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:

Pročitaj trenutno stanje.
Simuliraj poziv.
Zatraži potpis.
Prikaži hash transakcije.
Sačekaj receipt.
Proveri status.
Sačekaj finalnost ako sledeća radnja ima poslovnu vrednost.
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:

Definišite koji deo sistema zaista mora biti on-chain.
Napravite ugovor bez čuvanja sredstava ako use-case to dozvoljava.
Napišite unit, fuzz i invariant testove.
Testirajte kontrole pristupa i sve terminalne state transitions.
Pokrenite lokalni deployment i simulirajte neuspele pozive.
Objavite ugovor na BSC testnetu.
Verifikujte source i compiler konfiguraciju.
Testirajte wallet promenu mreže i pogrešan chain ID.
Izmerite gas za realne scenarije, ne samo za happy path.
Implementirajte idempotentni event indexer.
Razdvojte observed i finalized stanje.
Uvedite najmanje dva RPC providera za kritične servise.
Dokumentujte admin ključeve, mogućnost nadogradnje i proceduru incidenta.
Objavite mainnet deployment sa odvojenim deployer nalogom.
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

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
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
BNB Chain, “BNB Chain Fusion”: bnbchain.org/en/bnb-chain-fusion
BNB Chain dokumentacija, “BSC Validator Overview”: docs.bnbchain.org/bnb-smart-chain/validator/overview
BNB Chain dokumentacija, “Fermi Upgrade of BSC” i “Introduction”: docs.bnbchain.org/announce/fermi-bsc i docs.bnbchain.org/bnb-smart-chain/introduction
BNB Chain dokumentacija, “JSON-RPC Endpoint”: docs.bnbchain.org/bnb-smart-chain/developers/json_rpc/json-rpc-endpoint
Foundry dokumentacija, “Deploying and Verifying”: getfoundry.sh/forge/deploying
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
Volet Srbija

TRON za backend developere: TRC-20 plaćanja u praksi

Dora Milen — Fri, 18 Sep 2026 23:14:39 +0000

TRON je zanimljiviji kao infrastruktura nego kao ticker

TRON je Layer 1 blockchain sa sopstvenom virtuelnom mašinom, modelom naloga i Delegated Proof of Stake konsenzusom. TRX je njegov nativni asset, dok su TRC-20 tokeni smart contracti koji implementiraju standardizovani interfejs sličan ERC-20 standardu.

Za developera je važnija razlika između TRX-a i TRC-20 tokena nego tržišna cena TRX-a:

transfer TRX-a je sistemska transakcija
transfer TRC-20 tokena je poziv smart contracta
TRX transfer uglavnom troši Bandwidth
smart contract poziv troši Bandwidth i Energy
TRC-20 balans ne nalazi se direktno u TRON nalogu, već u stanju token contracta

TRON Virtual Machine, odnosno TVM, izvršava Solidity smart contracte i koristi Solidity ABI. Ipak, TRON nije Ethereum sa drugim RPC URL-om. Adrese, resursi, finalnost i deo API površine dovoljno su različiti da Ethereum integraciju ne treba prekopirati bez prilagođavanja.

TRON koristi 27 aktivnih Super Representative čvorova za proizvodnju blokova. Novi blok se u normalnim uslovima proizvodi približno svake tri sekunde. To daje brz signal da je transakcija uključena, ali uključenje u blok nije isto što i finalno knjiženje. Za finansijski ledger treba sačekati da blok postane solidified, što tipično traje oko jednog minuta.

To je prvi važan mentalni model: aplikacija može brzo prikazati da je uplata primećena, ali raspoloživo stanje treba menjati tek kada koristi potvrđene, solidified podatke.

Gde TRON ima smisla za backend tim

TRON ima smisla kada korisnici ili poslovni partneri već koriste TRX ili TRC-20 tokene. Tipičan primer nije novi DeFi protokol, već mnogo običniji backend problem:

SaaS platforma želi da izdaje fakture i automatski prepoznaje uplate podržanog TRC-20 tokena.

Sistem za takav slučaj mora da:

dodeli adresu kupcu ili fakturi
prepozna dolazni transfer
proveri mrežu, token contract, primaoca i iznos
sačeka solidifikaciju
knjiži uplatu tačno jednom
kasnije prebaci sredstva u treasury wallet
uskladi interni ledger sa stanjem na mreži

Blockchain deo ovde nije najteži. Teži deo je dizajn pouzdanog platnog workflowa oko njega.

Ako se TRON koristi samo zato što deluje jeftinije od neke druge mreže, to obično nije dovoljan razlog. Trošak zavisi od vrste transakcije, stanja primaoca, trenutnog Energy faktora contracta i raspoloživih resursa naloga. Mnogo bolji signal je postojeća potražnja korisnika i kompatibilnost sa njihovim walletima.

Model naloga i adresa koji utiče na integraciju

TRON adrese se pojavljuju u dva oblika:

Base58Check format, obično dužine 34 karaktera i sa početnim slovom T
heksadecimalni format sa prefiksom 41

Oba predstavljaju istu 21-bajtnu adresu. Kada koristite native HTTP API, polje visible određuje koji format endpoint očekuje. Sa visible: true koriste se Base58Check adrese. Ako je visible izostavljen ili postavljen na false, API uglavnom očekuje hex format.

Kod ABI enkodiranja contract parametara postoji dodatna zamka: prefiks 41 se uklanja, pa se enkodira 20-bajtna adresa kao u standardnom Solidity ABI-ju. SDK poput TronWeb-a ovo rešava automatski, ali ručno enkodiranje često dovodi do CONTRACT_VALIDATE_ERROR grešaka.

Mreža takođe mora biti deo poslovnog identiteta adrese. Mainnet, Shasta i Nile koriste isti adresni prefiks. Na osnovu stringa koji počinje slovom T ne možete zaključiti kojoj mreži pripada.

Praktičan složeni ključ zato izgleda ovako:

network + address

Za token je potreban još stroži identitet:

network + contract_address

Simbol poput USDT, USD ili TOKEN nije identitet asseta. Simboli mogu biti duplirani, a bilo ko može postaviti contract sa poznatim imenom. Produkcioni sistem treba da ima eksplicitnu allowlistu contract adresa.

TRC-20 nije samo poziv funkcije `transfer`

TRC-20 standard definiše funkcije kao što su balanceOf, transfer, transferFrom, approve i allowance, kao i događaje Transfer i Approval.

Na površini, slanje tokena izgleda jednostavno:

transfer(address recipient, uint256 amount)

Za payment backend je, međutim, važnije kako se transfer otkriva nego kako se šalje.

Nije dovoljno pročitati ulazne parametre TriggerSmartContract transakcije i zaključiti da je izvršen transfer. Smart contract može:

emitovati više Transfer događaja
izvršiti transfer kroz drugi contract
pozvati transferFrom
završiti sa revertom
imati ulazne parametre koji ne odgovaraju konačnim promenama stanja

Pouzdan scanner zato posmatra uspešno izvršenu transakciju i dekodira Transfer(address,address,uint256) događaje iz receipt logova. Contract koji je emitovao događaj mora odgovarati dozvoljenom token contractu, a primalac mora biti adresa koju platforma kontroliše.

Jedna transakcija može emitovati više transfer događaja. txID zato nije nužno dovoljan kao jedinstveni identifikator jednog token transfera. Robusniji ključ je:

network + tx_id + event_index

Ako koristite sopstveni block scanner, sačuvajte i broj bloka, hash bloka, poziciju transakcije i poziciju loga. To kasnije znatno olakšava audit i ponovno procesiranje.

Realna arhitektura za prijem TRC-20 uplata

Minimalna produkciona arhitektura ima nekoliko odvojenih odgovornosti.

Komponenta	Odgovornost
Address service	Dodeljuje i evidentira deposit adrese
Chain scanner	Pronalazi potvrđene transfere
Deposit processor	Validira pronađene transfere
Ledger	Knjiži poslovnu promenu tačno jednom
Sweeper	Prebacuje sredstva u treasury wallet
Signer	Izolovano potpisuje izlazne transakcije
Reconciliation job	Poredi blockchain stanje i interni ledger

Scanner ne treba da ima privatne ključeve. Za pretragu blokova, događaja i stanja dovoljni su javni podaci. Signer treba da bude zaseban proces ili servis sa minimalnom API površinom.

Osnovne tabele mogu izgledati ovako:

asset_registry
    network
    contract_address
    symbol
    decimals
    deposits_enabled
    withdrawals_enabled

deposit_address
    network
    address
    customer_id
    derivation_reference
    activation_status

onchain_transfer
    network
    tx_id
    event_index
    block_number
    block_hash
    contract_address
    from_address
    to_address
    raw_amount
    status

ledger_entry
    account_id
    asset_id
    raw_amount
    source_type
    source_id

scanner_cursor
    network
    last_solidified_block

Iznose treba čuvati kao cele brojeve u najmanjoj jedinici tokena. Nemojte konvertovati blockchain iznose u float ili JavaScript number ako mogu preći bezbedni celobrojni opseg.

Ako transfer nosi vrednost "1250000", a dozvoljeni asset ima šest decimala, ledger treba da sačuva "1250000". Prikaz 1.25 je posao prezentacionog sloja.

Metapodatke poput simbola i broja decimala možete inicijalno pročitati sa contracta, ali produkcioni asset registry treba da ih kontroliše kao verzionisanu konfiguraciju. Nemojte dozvoliti da odgovor indexera samostalno redefiniše način na koji se novac prikazuje i knjiži.

TronGrid za početak, sopstveni scanner za veću kontrolu

TRON integracija obično počinje jednim od dva pristupa:

hosted servis kao što je TronGrid
sopstveni FullNode, SolidityNode i indexer

TronGrid nudi standardne node API-je i dodatne indeksirane endpointove za istoriju naloga, TRC-20 transfere i contract događaje. Za istoriju dolaznih TRC-20 transfera postoji endpoint:

GET /v1/accounts/{address}/transactions/trc20

Endpoint podržava filtere kao što su only_confirmed, only_to, contract_address, vremenski opseg, sortiranje i paginacija preko fingerprint vrednosti.

Minimalni test sa Shasta ili Mainnet konfiguracijom može izgledati ovako:

curl --get \
  "$TRON_API/v1/accounts/$ADDRESS/transactions/trc20" \
  --header "TRON-PRO-API-KEY: $TRON_API_KEY" \
  --data-urlencode "only_confirmed=true" \
  --data-urlencode "only_to=true" \
  --data-urlencode "contract_address=$TOKEN_CONTRACT" \
  --data-urlencode "limit=200"

TRON_API treba eksplicitno vezati za okruženje:

Mainnet: https://api.trongrid.io
Shasta: https://api.shasta.trongrid.io
Nile: https://nile.trongrid.io

Produkcioni kod mora da implementira paginaciju. Ako odgovor sadrži meta.fingerprint, sledeći zahtev treba poslati sa istim filterima i dodatim fingerprint parametrom. Promena ostalih filtera tokom paginacije može proizvesti rupe ili duplikate.

TronGrid je praktičan za prototip i umeren saobraćaj, ali uvodi zavisnost od rate limita, plana usluge i kašnjenja indexera. Za kritičan ledger indeksirani rezultat može biti kandidat za uplatu, dok se konačna verifikacija radi nad solidified podacima.

Kod većeg obima alternativni model je skeniranje svakog novog solidified bloka:

pročitaj poslednji solidified block number
preuzmi sve blokove od lokalnog kursora do tog broja
proveri execution receipt za smart contract transakcije
dekodiraj relevantne Transfer događaje
upiši rezultate i novi kursor u kontrolisanim transakcijama

TRON dokumentacija za exchange i custodial integracije preporučuje upravo oslanjanje na solidified visinu, a ne na trenutni chain head.

Hosted API i sopstveni node nisu međusobno isključivi. Čest kompromis je sopstveni node za verifikaciju, emitovanje transakcija i reconciliation, uz hosted indexer za pretrage koje nisu deo kritičnog puta.

Finalnost, idempotencija i stanje uplate

Payment state machine ne treba da bude samo pending i paid. Korisniji model je:

created
observed
solidified
credited
sweeping
swept
rejected
manual_review

observed znači da je transfer primećen blizu chain heada ili u indexeru. To još nije dozvola za knjiženje raspoloživog salda.

solidified znači da je uplata pronađena u finalizovanom delu lanca.

credited znači da je interni ledger uspešno promenjen.

credited i solidified nisu isto stanje. Blockchain može biti potpuno ispravan, a vaš database transaction može pasti. Zato ledger unos mora imati jedinstveni ključ povezan sa on-chain događajem.

Primer zaštite na nivou baze:

create unique index uq_onchain_transfer
on onchain_transfer (network, tx_id, event_index);

Ledger unos treba da ima sličnu zaštitu:

create unique index uq_ledger_source
on ledger_entry (source_type, source_id);

Ako worker obradi isti događaj više puta, drugi pokušaj treba da završi kao bezopasan conflict, a ne kao drugo knjiženje.

Webhook prema ostatku aplikacije šaljite kroz transactional outbox. U suprotnom možete uspešno knjižiti uplatu, pasti pre slanja događaja i ostaviti order servis u pogrešnom stanju.

Koliko košta transakcija na TRON-u

TRON nema jedan univerzalni gas fee. Trošak se sastoji od mrežnih resursa i eventualnih direktnih protokolskih naknada.

Bandwidth

Bandwidth pokriva bajtove koje transakcija zauzima na mreži. Prema parametrima proverеним 19. septembra 2026, nalog ima do 600 besplatnih Bandwidth jedinica u kliznom periodu od 24 sata. Dodatni Bandwidth može se dobiti stakingom TRX-a.

Ako raspoloživi Bandwidth nije dovoljan, mreža može spaliti TRX po trenutno važećoj ceni. Dokumentacija u trenutku provere navodi 1.000 sun po nepokrivenom bajtu.

Energy

Energy pokriva izvršavanje TVM instrukcija. Contract pozivi, uključujući TRC-20 transfere, troše Energy. Za Energy ne postoji besplatna kvota.

Energy se može obezbediti:

stakingom TRX-a
delegiranjem resursa sa drugog naloga
spaljivanjem TRX-a za nepokriveni deo

U trenutku provere, aktuelna dokumentacija navodi cenu od 100 sun po jedinici Energy-ja. Ova vrednost je chain parameter i može biti promenjena kroz governance.

Jedan TRX sadrži 1.000.000 sun, pa se približan obračun može predstaviti ovako:

burn_sun =
    uncovered_bandwidth * bandwidth_price
    + uncovered_energy * energy_price
    + direct_protocol_fees

burn_trx = burn_sun / 1_000_000

Ovo nije unapred garantovana cena. Contract stanje i Dynamic Energy Model mogu promeniti Energy potreban za isti poziv. Popularni contracti mogu imati dodatni Energy faktor koji se menja tokom vremena.

Zato produkcioni servis treba da proceni Energy neposredno pre slanja transakcije i da tada postavi fee_limit.

Šta zapravo radi `fee_limit`

fee_limit je izražen u sun i ograničava caller-side Energy budžet jedne smart contract transakcije. On nije fiksna naknada koja se automatski naplaćuje u celosti.

Ako postavite fee_limit na 100 TRX, to ne znači da će transakcija koštati 100 TRX. To znači da transakcija ne sme koristiti veći caller-side Energy budžet od tog limita. Naplaćuje se stvarno potrošen nepokriveni Energy, osim kod određenih failure scenarija koji mogu iscrpeti raspoloživi budžet.

Prenizak limit proizvodi OUT_OF_ENERGY, čak i kada nalog ima TRX. Previsok limit povećava izloženost skupom failure pathu. Razumna strategija je:

simulirati ili proceniti poziv
pročitati aktuelni getEnergyFee
uzeti u obzir trenutni ili maksimalni dynamic Energy faktor
dodati kontrolisanu rezervu
odbiti transakciju ako procena prelazi poslovni limit

Chain parametre treba čitati preko wallet/getchainparameters, a ne trajno upisati u kod.

Aktivacija adrese

Lokalno generisana adresa ne postoji kao aktivan on-chain nalog dok ne bude aktivirana.

Standardna aktivacija trenutno nosi direktnu naknadu od 1 TRX. Ako pošiljalac nema dovoljno Bandwidth resursa, može se spaliti još 0,1 TRX za Bandwidth shortfall.

To je važno kod modela sa posebnom deposit adresom za svakog korisnika. Generisanje adrese je praktično besplatno, ali njena aktivacija, kasniji sweep i upravljanje ključem nisu.

Veliki broj jednokratnih adresa poboljšava atribuciju uplata, ali povećava:

broj ključeva koje morate bezbedno derivirati i oporaviti
broj naloga koje treba aktivirati
broj sweep transakcija
potrebu za delegiranjem Bandwidth i Energy resursa
reconciliation površinu

Zajednička adresa smanjuje operativni trošak, ali komplikuje atribuciju. Oslanjanje isključivo na memo nije idealno jer standardni TRC-20 transfer nema poslovno polje za identifikator fakture, a walleti ne nude uvek dosledan način za slanje transaction memo podataka.

Slanje i sweepovanje tokena

Nakon što je uplata knjižena, tokeni obično ne ostaju trajno na deposit adresi. Sweeper ih periodično prebacuje u treasury ili hot wallet.

Za svaki sweep potrebno je:

proveriti da je adresa aktivna
proveriti stvarni balanceOf
proceniti Energy
obezbediti Energy, Bandwidth ili dovoljan TRX saldo
napraviti unsigned transakciju
poslati je izolovanom signer-u
emitovati potpisanu transakciju
pratiti receipt do solidifikacije
povezati rezultat sa internim sweep nalogom

Ako svaka deposit adresa sama šalje TRC-20 tokene, svaka mora moći da potpiše contract transakciju i pokrije resurse. Treasury nalog može delegirati Energy i Bandwidth deposit adresama, čime se smanjuje potreba da se TRX šalje na svaku pojedinačnu adresu.

To ipak uvodi sopstveni resource scheduler. Potrebno je pratiti koliko je resursa delegirano, koliko je raspoloživo i kada ih treba povući ili preraspodeliti.

Za nizak obim često je jednostavnije spaliti kontrolisanu količinu TRX-a. Za visok i predvidiv obim staking i delegiranje mogu smanjiti operativni burn, ali vezuju kapital. Aktuelni Stake 2.0 model ima period čekanja pre povlačenja unstakeovanog TRX-a, trenutno 14 dana, pri čemu i taj parametar treba čitati sa mreže.

TronWeb i granice SDK-a

Za JavaScript i TypeScript TronWeb je prirodan SDK. Može da se poveže sa Mainnetom, Shasta ili Nile mrežom preko fullHost konfiguracije i podržava API key zaglavlje za TronGrid.

Tipična konfiguracija izgleda ovako:

import { TronWeb } from "tronweb";

const tronWeb = new TronWeb({
    fullHost: process.env.TRON_FULL_HOST,
    headers: {
        "TRON-PRO-API-KEY": process.env.TRON_API_KEY,
    },
});

Ovaj instance nema private key i pogodan je za čitanje stanja, validaciju adresa i pripremu nepotpisanih operacija.

Nemojte automatski dodavati private key u svaki TronWeb instance samo zato što SDK to podržava. Scanner, REST kontroleri i javni web procesi ne treba da mogu da potpisuju transakcije.

Za prototip na Shasta testnetu izolovani testni ključ je prihvatljiv. U produkciji potpisivanje treba izdvojiti u HSM, hardware wallet, offline signer ili strogo kontrolisan servis. Dokumentacija eksplicitno upozorava da se metode koje koriste private key ne izvršavaju u browseru ili korisničkoj aplikaciji.

TRON takođe nudi JSON-RPC kompatibilnost za deo Ethereum alata. Ona je korisna za postojeći Web3.js, ethers ili viem kod, ali ne pokriva nužno sve native node operacije. Kada su potrebni account resources, solidified state ili TRON-specifični API-ji, native HTTP API, gRPC ili TronWeb obično daju jasniji model.

Testiranje koje vredi uraditi pre Mainneta

Shasta je preporučeni testnet za standardne integracije i završnu proveru pre produkcije. Nile se više koristi za funkcionalnosti i parametre koji se tek približavaju Mainnetu. Testnet TRX i testni TRC-20 tokeni mogu se dobiti kroz zvanične faucet tokove.

Happy-path transfer nije dovoljan test. Korisniji skup scenarija uključuje:

isti događaj preuzet više puta
više Transfer događaja u jednoj transakciji
isti simbol sa pogrešne contract adrese
uplatu na Mainnet adresu dok servis radi u Shasta okruženju
iznos veći od JavaScript Number.MAX_SAFE_INTEGER
transfer ispod poslovnog minimuma
transfer koji je primećen, ali još nije solidified
contract transakciju koja je završila revertom
restart scannera između upisa transfera i pomeranja kursora
TronGrid timeout nakon uspešnog odgovora mreže
neuspešan sweep zbog preniskog fee_limit
promenu Energy procene između simulacije i izvršenja
ponovni broadcast iste potpisane transakcije
nedostupan signer
neslaganje između ukupnog on-chain balansa i internog ledgera

Posebno testirajte oporavak. Ako scanner izgubi lokalni kursor, mora postojati način da ponovo pročita opseg solidified blokova bez dvostrukog knjiženja.

Trade-off koji se najčešće previdi

TRON smanjuje vreme potrebno da developer dođe do prve token transakcije, ali ne uklanja složenost custody sistema.

Prednosti su praktične:

Solidity i poznat ABI model
brz block cadence
standardizovan TRC-20 interfejs
hosted API i indexer za brz početak
staking i delegiranje kao alternativa stalnom spaljivanju TRX-a
solidified API površina pogodna za finansijski ledger

Ograničenja su podjednako konkretna:

Energy trošak smart contract poziva nije fiksan
adrese zahtevaju aktivaciju i resource planiranje
Ethereum tooling nije potpuna zamena za native TRON API
hosted indexer zahteva paginaciju, rate-limit strategiju i verifikaciju
veliki broj deposit adresa povećava custody i sweep složenost
brzo uključenje u blok nije isto što i finalno knjiženje
upravljanje ključevima ostaje najveći operativni rizik

Za non-custodial aplikaciju deo ovog problema preuzima korisnički wallet. Korisnik potpisuje sopstvene transakcije, dok backend prati događaje i poslovno stanje.

Za custodial payment servis nema takvog prečaca. TRON deo integracije može biti relativno kompaktan, ali kvalitet sistema zavisi od dosadnih detalja: celobrojnih iznosa, finalnosti, idempotentnog ledgera, izolovanog signer-a i redovnog reconciliation procesa.

To je ujedno i dobar način da se tehnologija proceni. Mali Shasta prototip sa jednom dozvoljenom TRC-20 adresom, solidified scannerom i idempotentnim ledgerom otkriva mnogo više od jednostavnog poziva transfer.

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

Ripple, XRP i XRPL: detaljna arhitektura za developere

Dora Milen — Fri, 18 Sep 2026 22:49:36 +0000

Termin „Ripple” često se koristi kao zajedničko ime za kompaniju, mrežu i kriptovalutu. Za developera je to loš početni model, jer su u pitanju tri odvojene stvari:

Ripple je privatna tehnološka kompanija koja razvija infrastrukturu i proizvode za digitalna plaćanja.
XRP Ledger, skraćeno XRPL, jeste javna, open-source Layer 1 mreža.
XRP je nativni digitalni asset te mreže.

Ripple koristi XRPL i XRP u delu svojih proizvoda, poseduje XRP i doprinosi razvoju ekosistema, ali XRPL nije Ripple-ov privatni blockchain. Aplikacija može koristiti XRP Ledger bez poslovnog odnosa sa kompanijom Ripple.

Za developera je zato preciznije pitanje: šta XRPL pruža kao platforma, kako izgleda integracija i za koje probleme je njegov model bolji od generičkog smart contract blockchaina?

Šta je XRP Ledger

XRP Ledger je distribuirani state machine optimizovan za prenos i razmenu vrednosti. Pokrenut je 2012. godine, a njegov nativni asset je XRP. Ukupno 100 milijardi XRP kreirano je na početku mreže. Protokol ne rudari nove jedinice, dok se XRP potrošen na transakcione troškove trajno uništava.

Za razliku od platformi kod kojih gotovo svaka poslovna funkcija zahteva poseban smart contract, XRPL u sam protokol ugrađuje finansijske primitive:

direktna XRP plaćanja
izdavanje fungibilnih tokena
trust lines
cross-currency plaćanja
central limit order book DEX
automated market makere
escrow
payment channels
checks
NFT objekte
multi-signing
kontrole kao što su autorizacija, freeze i clawback

To je važna arhitektonska razlika. XRPL nije zamišljen kao globalni računar opšte namene, već kao finansijski ledger sa unapred definisanim tipovima transakcija i objekata.

Ako aplikaciji trebaju plaćanja, tokenizovana potraživanja, razmena asseta ili settlement, takav model može ukloniti veliki deo smart contract koda. Ako joj treba proizvoljna izvršna logika, petlje, kompleksno stanje i composability sa Solidity protokolima, osnovni XRPL verovatno nije dovoljan.

Kako XRPL čuva stanje

XRPL koristi account-based model, ali njegov nalog nije samo stanje sa nativnim balansom.

Osnovni zapis naloga je AccountRoot. On sadrži:

klasičnu adresu naloga
XRP balans
Sequence broj
konfiguracione flagove
broj objekata koji utiču na rezervu
pokazivače ka prethodnoj transakciji

Dodatne funkcije predstavljene su posebnim ledger objektima. Trust line je RippleState, otvorena ponuda na DEX-u je Offer, escrow je Escrow, a konfiguracija za multi-signing čuva se kao SignerList.

Svaka validirana verzija ledgera sadrži aktuelno stanje, skup transakcija koje su dovele do tog stanja i kriptografske reference ka prethodnoj verziji. Node zato može proveravati trenutno stanje bez rekonstrukcije čitave istorije od genesis bloka.

Adrese i aktivacija naloga

Klasična XRPL adresa:

obično počinje slovom r
izvedena je iz javnog ključa
sadrži checksum
razlikuje velika i mala slova

Generisanje ključa i adrese ne kreira automatski nalog u ledgeru. Adresa postaje aktivan nalog tek kada primi dovoljno XRP da ispuni minimalnu rezervu.

Ne postoji posebna CreateAccount transakcija. Običan Payment koji pošalje dovoljno XRP na novu adresu kreira njen AccountRoot.

Pored klasičnih adresa postoje X-address formati. Oni kombinuju klasičnu adresu i destination tag u jedan string. Sam protokol i dalje nativno koristi klasičnu adresu i poseban DestinationTag, dok SDK može obaviti konverziju.

Uloga XRP-a u protokolu

XRP nije ERC-20-stil token dodat naknadno. On je deo osnovnog računovodstvenog modela XRPL-a i ima nekoliko tehničkih funkcija.

Prenos vrednosti

XRP se može direktno poslati između naloga bez izdavaoca, trust linea ili smart contracta. Iznos se u API-jima najčešće predstavlja u jedinici drop:

1 XRP je 1.000.000 drops
0,1 XRP je 100.000 drops
0,00001 XRP je 10 drops

Zbog toga XRP vrednosti u transakcijama ne treba predstavljati JavaScript number tipom i ručno množiti. SDK funkcije kao što je xrpl.xrpToDrops() smanjuju rizik od grešaka sa decimalama.

Zaštita od spama

Svaka standardna transakcija uništava malu količinu XRP-a. Minimalni trošak standardne transakcije trenutno je 10 drops, odnosno 0,00001 XRP, ali server može zahtevati više kada je pod opterećenjem.

Fee nije nagrada validatoru. XRP naveden u ovom polju trajno se uklanja iz opticaja.

Rezerva za stanje

XRPL traži da nalog drži određenu XRP rezervu:

osnovna rezerva naloga trenutno je 1 XRP
dodatna owner rezerva trenutno je 0,2 XRP po ledger objektu

Trust lines, ponude, escrow objekti i slični zapisi mogu povećati potrebnu rezervu. Rezerva nije isto što i transakcioni trošak. Ona uglavnom ostaje u balansu, ali se ne može slobodno poslati dok odgovarajući objekat postoji.

Bridge asset

XRP može povezati dva asseta na ugrađenom DEX-u. Ako ne postoji dovoljno likvidnosti za direktnu razmenu između dva tokena, XRPL može razmotriti putanju token A, XRP, token B.

Ova funkcija nije garancija dobrog kursa. Ona samo omogućava protokolu da koristi raspoložive order bookove i AMM likvidnost u okviru jedne atomske transakcije.

Kako radi XRPL konsenzus

XRPL ne koristi proof of work i nema rudare. Ne koristi ni klasični proof of stake u kojem količina zaključanog tokena direktno određuje pravo na proizvodnju blokova.

Serveri izvršavaju transakcije, održavaju ledger i prate validatore. Svaki server bira skup validatora kojima veruje da neće koordinisano kršiti protokol. Taj skup se naziva Unique Node List, odnosno UNL.

Proces, pojednostavljeno, izgleda ovako:

Server prima kandidat transakcije.
Validatori predlažu skup transakcija za narednu verziju ledgera.
Predlozi se porede u više rundi.
Validatori prilagođavaju predlog prema transakcijama koje imaju dovoljan nivo podrške.
Transakcije se izvršavaju determinističkim redosledom.
Validatori objavljuju validacije rezultujućeg ledgera.
Kada server dobije potreban nivo podrške svojih trusted validatora, ledger smatra validiranim.

Ledger se tipično zatvara i validira u periodu od nekoliko sekundi. Dokumentacija kao uobičajen interval navodi približno tri do pet sekundi.

Prema bezbednosnom modelu protokola, konsenzus može normalno napredovati dok je manje od 20 procenata trusted validatora neispravno. Potvrđivanje nevalidnog rezultata zahtevalo bi koordinaciju više od 80 procenata validatora kojima konkretan server veruje.

To otkriva i glavni trade-off. Bezbednost ne zavisi od anonimne hash snage ili ukupno uloženog kapitala, već od kvalitetnog, raznovrsnog i dovoljno preklopljenog izbora validatora. Operater node-a može definisati svoj UNL, ali time preuzima odgovornost da njegov izbor ostane kompatibilan sa ostatkom mreže.

Konsenzus nije isto što i izvršavanje transakcije

Odgovor servera nakon submit poziva nije konačna potvrda.

Server prvo može privremeno izvršiti transakciju nad otvorenim ledgerom. Redosled i stanje tokom konsenzusa mogu se promeniti, pa početni rezultat može biti drugačiji od rezultata u validiranom ledgeru.

Aplikacija sme da tretira ishod kao konačan tek kada:

transakcija postoji u validiranom ledgeru
odgovor ima validated: true
meta.TransactionResult ima očekivanu vrednost, najčešće tesSUCCESS

Za transakcije koje nisu prošle, konačan neuspeh može se utvrditi nakon što prođe njihov LastLedgerSequence i pouzdan server potvrdi da transakcija nije uključena ni u jedan odgovarajući ledger.

Anatomija transakcije

Tipična XRPL transakcija sadrži:

{
  "TransactionType": "Payment",
  "Account": "rSenderAddress",
  "Destination": "rDestinationAddress",
  "DeliverMax": "1250000",
  "Fee": "10",
  "Sequence": 42,
  "LastLedgerSequence": 98765432
}

Značenje ključnih polja:

TransactionType određuje protokolsku operaciju.
Account je nalog koji autorizuje i plaća transakciju.
Destination je primalac kod Payment transakcije.
DeliverMax je maksimalan iznos koji treba dostaviti, ovde izražen u drops.
Fee je maksimalni XRP iznos koji će biti uništen.
Sequence sprečava replay i određuje redosled transakcija jednog naloga.
LastLedgerSequence definiše poslednji ledger u kojem transakcija sme biti uključena.

U API verziji 1 tradicionalno se koristi polje Amount. API verzija 2 za Payment preferira naziv DeliverMax, koji jasnije opisuje semantiku polja, naročito kod partial payment transakcija.

Sequence i konkurentnost

Nalog ima trenutni Sequence. Transakcija uspeva samo ako koristi odgovarajuću vrednost. Nakon procesiranja, sequence naloga se povećava.

To je jednostavno kada jedan proces šalje transakcije sekvencijalno. Postaje složenije kada:

više worker procesa koristi isti nalog
payout sistem šalje stotine naloga paralelno
dođe do timeouta posle slanja, ali pre čuvanja rezultata
jedna transakcija ostane u queue-u

Tipična rešenja su:

jedan centralni sequence allocator
red za slanje po nalogu
više operativnih naloga
XRPL Tickets za unapred rezervisane brojeve transakcija
pažljivo čuvanje potpisanog blob-a, hash-a i LastLedgerSequence

Nije dovoljno ponovo napraviti „istu” poslovnu transakciju posle timeouta. Prvo se proverava originalni hash, jer je moguće da je original već validiran.

Plaćanja nisu samo transfer balansa

Payment je jedna od najvažnijih XRPL transakcija, ali može predstavljati nekoliko različitih operacija:

direktan XRP transfer
direktan transfer tokena
izdavanje tokena
cross-currency plaćanje
konverziju asseta kroz DEX
partial payment
kreiranje novog naloga XRP uplatom

Kod cross-currency plaćanja pošiljalac može definisati koliko jednog asseta želi da potroši, a koliko drugog asseta primalac treba da dobije. Protokol zatim može atomski koristiti putanje kroz trust lines, order bookove i AMM poolove.

Ako puna razmena nije moguća pod zadatim uslovima, cela transakcija može pasti. Ako je uključen tfPartialPayment, ona može uspeti sa manjim isporučenim iznosom.

Zbog toga backend nikada ne treba da kreditira korisnika na osnovu DeliverMax ili starog Amount polja. Stvarno dostavljeni iznos čita se iz meta.delivered_amount ili se računa iz promena balansa u metadata objektu.

Tokeni: trust lines i MPT

XRPL ima dva modela fungibilnih tokena.

Trust line tokeni

Originalni model koristi RippleState objekte, poznate kao trust lines. Asset je identifikovan kombinacijom:

currency koda
adrese izdavaoca

USD koji izdaje jedan nalog nije isti asset kao USD koji izdaje drugi nalog.

Holder pre primanja tokena uglavnom kreira trust line ka izdavaocu. Trust line izražava spremnost naloga da drži određeni asset i postavlja maksimalni limit.

Izdavalac može konfigurisati funkcije kao što su:

obavezna autorizacija holdera
transfer fee
global freeze
individual freeze
clawback, ako je prethodno omogućen
zabrana freeze funkcije njenim trajnim isključivanjem

Trust line model je moćan, ali ima istorijske osobine koje nisu uvek intuitivne. Stanje je bidirekciono, balans zavisi od perspektive strane, a rippling može omogućiti tok obaveza kroz više naloga. Za klasičan stablecoin proizvod obično se pažljivo konfiguriše No Ripple i razdvajaju issuing, operational i standby nalozi.

Multi-Purpose Tokens

Multi-Purpose Tokens, odnosno MPT, predstavljaju noviji model fungibilnih tokena. Svako izdanje ima poseban identifikator i eksplicitnije odvojene uloge izdavaoca i holdera.

MPT model podržava osobine kao što su:

maksimalna ponuda
transfer fee
holder autorizacija
zabrana transfera
freeze
clawback
on-chain metadata

MPT funkcije uvode se kroz amendment sistem. Podršku treba proveriti na konkretnoj mreži i u verziji servera i SDK-a koju aplikacija koristi. Neke dodatne funkcije, kao što je šira integracija MPT-a sa DEX-om, razvijaju se odvojeno kroz novije amendmente.

Za novi token projekat izbor nije samo „stari ili novi standard”. Potrebno je proveriti da li svi potrebni walleti, custody sistemi, berze i analytics servisi podržavaju izabrani model.

Ugrađeni DEX i AMM

XRPL DEX kombinuje central limit order book model i automated market makere.

Offer kao limit nalog

OfferCreate opisuje koliko jednog asseta nalog nudi i koliko drugog želi zauzvrat. Ako postoji odgovarajuća kontra-ponuda, razmena se izvršava odmah. Neispunjeni deo može ostati kao Offer objekat u ledgeru.

Pošto je ponuda ledger objekat, ona može povećati owner rezervu naloga.

Matching počinje od najboljeg kursa. Transakcija može biti potpuno ili delimično izvršena, u zavisnosti od flagova i raspoložive likvidnosti.

AMM poolovi

XRPL AMM drži par asseta i koristi constant-product-stil model. Liquidity provideri dobijaju LP tokene koji predstavljaju njihov udeo u poolu.

Kada transakcija traži razmenu, protokol može koristiti:

samo order book
samo AMM
kombinaciju order book ponuda i AMM likvidnosti

Izbor zavisi od dostupnog kursa i pravila same transakcije. AMM ima sopstveni trading fee koji određuju liquidity provideri, dok mrežni Fee ostaje zaseban trošak protokola.

Ugrađen DEX smanjuje količinu aplikativnog koda, ali ne uklanja tržišne rizike:

slippage
nedovoljnu likvidnost
manipulaciju tankim tržištem
issuer rizik tokena
impermanent loss za liquidity providere
nepredvidiv krajnji kurs ako transakcija nema stroge granice

Backend zato treba da računa quote neposredno pre slanja i postavi SendMax, DeliverMin ili quality ograničenja u skladu sa poslovnim pravilima.

Realan use-case: payment backend sa zajedničkim nalogom

Zamislimo SaaS platformu koja svojim korisnicima omogućava:

XRP depozite
depozite jednog podržanog stablecoina
interno knjiženje balansa
povlačenje na spoljne XRPL adrese
opcionu konverziju između XRP-a i stablecoina

Najjednostavniji model nije jedan XRPL nalog po korisniku. Svaki nalog zahteva rezervu i povećava operativni teret.

Platforma može koristiti jedan operational nalog za depozite, dok svakom korisniku dodeljuje jedinstven DestinationTag. Tag je 32-bitni broj koji nema samostalno on-chain značenje. Backend ga mapira na korisnika, fakturu ili nalog.

Workflow depozita

Korisnik dobija adresu i destination tag.
Platforma prati transakcije koje utiču na operational nalog.
Za svaku pristiglu transakciju proverava da li je rezultat validiran.
Proverava da je meta.TransactionResult jednak tesSUCCESS.
Proverava Destination i DestinationTag.
Stvarni primljeni iznos čita iz delivered_amount.
Proverava currency i issuer, ne samo ticker.
Upisuje ledger index i transaction hash.
Tek tada kreditira interni balans korisnika.

Operational nalog može uključiti RequireDest opciju kako bi mreža odbila uplate bez destination taga. To ne rešava pogrešan tag, pa su i dalje potrebni reconciliation i support procesi.

Workflow povlačenja

Korisnik šalje destination adresu, tag i traženi iznos.
Backend validira format adrese i proverava poslovna ograničenja.
Interna baza rezerviše iznos za payout.
Signing servis konstruiše transakciju.
autofill pribavlja Sequence, Fee i LastLedgerSequence.
Transakcija se potpisuje u izolovanom signing okruženju.
Potpisani blob i hash čuvaju se pre slanja.
Blob se šalje jednom ili više trusted servera.
Sistem čeka validirani rezultat.
Interno knjiženje postaje konačno tek nakon verifikacije.

Za direktan XRP payout nije potreban DEX. Za cross-currency payout treba eksplicitno ograničiti maksimalnu potrošnju i proveriti raspoloživu likvidnost.

Minimalna integracija pomoću xrpl.js

Zvanični JavaScript i TypeScript SDK instalira se kao paket xrpl:

npm install xrpl

Sledeći primer kreira dva Testnet naloga, šalje 1,25 test XRP i čeka validirani rezultat:

import xrpl from 'xrpl'

const client = new xrpl.Client(
  'wss://s.altnet.rippletest.net:51233'
)

await client.connect()

try {
  const { wallet: sender } = await client.fundWallet()
  const { wallet: receiver } = await client.fundWallet()

  const payment = {
    TransactionType: 'Payment',
    Account: sender.address,
    Destination: receiver.address,
    DeliverMax: xrpl.xrpToDrops('1.25')
  }

  const prepared = await client.autofill(payment)
  const signed = sender.sign(prepared)

  const response = await client.submitAndWait(signed.tx_blob)
  const result = response.result.meta.TransactionResult

  if (result !== 'tesSUCCESS') {
    throw new Error(`Payment failed: ${result}`)
  }

  console.log({
    hash: signed.hash,
    ledgerIndex: response.result.ledger_index,
    result
  })
} finally {
  await client.disconnect()
}

client.autofill() popunjava polja kao što su Fee, Sequence i LastLedgerSequence. Potpis se obavlja lokalno pomoću Wallet.sign(), a mreži se šalje binarni potpisani blob.

client.fundWallet() pripada razvojnom Testnet workflow-u. Ne treba ga koristiti kao deo produkcione arhitekture, a Testnet i Mainnet ne treba da dele iste ključeve.

Za produkciju je važnije razumeti workflow nego skratiti ga na jedan SDK poziv. Sistem bi između sign() i submitAndWait() trebalo da trajno sačuva najmanje:

hash transakcije
potpisani blob
source nalog
sequence ili ticket
LastLedgerSequence
interni payment ID
očekivani asset i iznos

Tako proces nakon restarta može proveriti postojeću transakciju umesto da naslepo kreira novu.

Direktni API pristup

SDK nije obavezan. xrpld i Clio nude JSON-RPC i WebSocket API-je.

JSON-RPC je pogodan za:

account_info
account_tx
tx
fee
server_info
book_offers
podnošenje transakcija

WebSocket je pogodniji za:

praćenje novih ledgera
subscription na naloge
praćenje validiranih transakcija
održavanje payment listenera

Trenutno postoje API verzije 1 i 2. Aplikacija treba eksplicitno da kontroliše verziju, jer se nazivi i semantika pojedinih polja razlikuju.

Javni serveri su praktični za razvoj i povremene upite. Zvanična dokumentacija upozorava da Ripple-ovi javni serveri nisu namenjeni kontinuiranom poslovnom opterećenju i da mogu postati nedostupni. Produkcioni sistem obično koristi sopstveni xrpld, pouzdanog infrastrukturnog provajdera ili kombinaciju više izvora.

`xrpld` i Clio nisu ista komponenta

xrpld je core server koji:

učestvuje u peer-to-peer mreži
obrađuje i prosleđuje transakcije
prati konsenzus
može raditi kao validator
pruža javne i administrativne API-je

Clio je API server optimizovan za čitanje validiranih istorijskih podataka. Ne povezuje se direktno na P2P mrežu, već podatke dobija od xrpld servera i čuva ih u Cassandra ili ScyllaDB infrastrukturi.

Tipična veća instalacija koristi xrpld za mrežnu konekciju i submission, a Clio klaster za skaliranje read-heavy API saobraćaja.

Koliko košta korišćenje XRPL-a

Trošak ima tri odvojene kategorije.

Stavka	Trenutni protokolski iznos	Napomena
Standardna transakcija	10 drops	Može porasti usled opterećenja
Osnovna rezerva naloga	1 XRP	Nije obična naknada
Owner rezerva	0,2 XRP po objektu	Zavisi od tipa i broja objekata
`AccountDelete`	200.000 drops	Poseban transakcioni trošak
`AMMCreate`	200.000 drops	Poseban transakcioni trošak
Multi-signed transakcija	Osnovni fee puta broj potpisa plus jedan	Skalira se brojem potpisa

Ove vrednosti mogu se menjati glasanjem validatora. Produkcioni kod ne treba da ih hardkodira, već da koristi fee, server_state, server_info ili SDK autofill().

Fiat vrednost troška zavisi od tržišne cene XRP-a. Rezerva takođe predstavlja kapital koji aplikacija mora držati, posebno ako otvara veliki broj naloga, trust lines ili ponuda.

Pored protokola postoje infrastrukturni troškovi:

hosted RPC provajder
sopstveni xrpld
Clio i baza za istorijske upite
signing servis ili HSM
monitoring i alerting
reconciliation baza
compliance i custody sistemi

SDK i core protokol su open source, ali pouzdana produkciona integracija nije „besplatna” samo zato što je mrežni fee mali.

Upravljanje ključevima

XRPL podržava secp256k1 i Ed25519 ključeve. Master ključ je intrinzično povezan sa nalogom i ne može se zameniti, ali može biti deaktiviran. Nalog može postaviti rotirajući regular key i signer listu za multi-signing.

Razuman produkcioni model razdvaja:

issuing nalog, koji je što više offline
operational nalog, koji obavlja redovne transfere
standby nalog, koji se koristi pri incidentu
signing servis, koji nema direktan pristup poslovnoj bazi
watch-only servise, koji nemaju privatne ključeve

Master key se čuva offline, a redovne transakcije potpisuje regular key ili multi-signing konfiguracija. Kompromitovani regular key može se zameniti bez migracije svih ledger objekata i poslovnih odnosa na novu adresu.

Seed ne treba slati javnom serveru radi potpisivanja. Transakcija se konstruiše, potpisuje lokalno ili u namenskom custody sistemu, a mreži se šalje samo potpisani blob.

Amendments i verzionisanje protokola

XRPL uvodi promene transakcionih pravila kroz amendment sistem.

Nova funkcija se implementira u xrpld, nakon čega validatori mogu glasati za njenu aktivaciju. Amendment mora održati podršku veću od 80 procenata trusted validatora tokom dve nedelje da bi postao aktivan. Nakon aktivacije postaje deo pravila mreže.

Ovaj mehanizam ima praktične posledice:

Devnet može imati funkcije koje Mainnet nema.
Dokumentacija može opisivati funkciju pre njene Mainnet aktivacije.
Stara verzija servera može postati amendment-blocked.
SDK tipovi mogu podržavati polje koje konkretna mreža još ne prihvata.
Status amendmenta treba proveriti pri planiranju release-a.

Posebno treba biti oprezan sa novijim funkcijama kao što su MPT proširenja, permissioned tržišta, token escrow, lending i dodatne compliance mogućnosti.

Gde se uklapa EVM sidechain

Osnovni XRPL nema EVM i ne izvršava Solidity ugovore. XRPL EVM Sidechain je zaseban, Ethereum-kompatibilan Layer 1 izgrađen na Cosmos SDK-u, sa XRP-om kao gas assetom.

To omogućava korišćenje:

Solidity ugovora
Ethereum development alata
ERC-20 modela
EVM wallet infrastrukture

Ipak, EVM sidechain nije „Solidity direktno na XRPL Mainnetu”. To je odvojena mreža sa sopstvenim validatorima, stanjem i operativnim rizicima. Prebacivanje asseta između mreža uvodi bridge i cross-chain pretpostavke koje ne postoje kod nativnih XRPL transakcija.

Praktično pravilo je jednostavno:

Ako problem može da se izrazi pomoću nativnih XRPL transakcija, ta implementacija ima manje pokretnih delova.
Ako je potrebna proizvoljna izvršna logika, EVM okruženje pruža veću fleksibilnost uz veću površinu rizika.

Najčešće integracione greške

Kreditiranje na osnovu `Amount`

Kod partial payment transakcije deklarisani maksimum nije isto što i stvarno primljeni iznos. Koristi se meta.delivered_amount ili metadata balance diff.

Provera ticker simbola bez izdavaoca

USD jednog izdavaoca i USD drugog izdavaoca predstavljaju različite assete. Backend mora proveriti i currency i issuer.

Tretiranje `submit` odgovora kao finalnog

Početni rezultat može biti privremen. Poslovna akcija se izvršava tek nad validiranim rezultatom.

Ponovno slanje posle timeouta

Timeout ne znači da transakcija nije prihvaćena. Prvo se proveravaju hash i LastLedgerSequence, pa se tek onda odlučuje o zameni.

Jedna adresa po korisniku

To povećava kapital zaključan u rezervama i komplikuje upravljanje ključevima. Za custody aplikacije shared address plus destination tags često je efikasniji model.

Korišćenje javnog endpointa kao produkcionog SLA-a

Javni server je koristan za testiranje, ali ne treba da bude jedina kritična zavisnost payment sistema.

Držanje issuing ključa online

Kompromitovan issuing nalog može ugroziti ceo token. Izdavanje, svakodnevna distribucija i emergency operacije treba razdvojiti.

Kada XRPL ima smisla

XRPL je posebno zanimljiv kada aplikaciji treba:

direktan settlement digitalnih asseta
veliki broj relativno jednostavnih plaćanja
stablecoin ili token sa issuer kontrolama
atomska konverzija i plaćanje
ugrađen order book i AMM
escrow bez deploymenta posebnog contracta
multi-currency payment routing
jednostavniji audit trail od kompleksnog contract sistema

Manje je prirodan izbor kada je primarni zahtev:

proizvoljna on-chain poslovna logika
permissionless deployment novih contract protokola
privatnost transakcija kao podrazumevana osobina
oslanjanje na postojeći Ethereum DeFi ekosistem
potpuno uklanjanje issuer ili bridge rizika
izvršavanje velikog broja paralelnih transakcija iz jednog naloga bez sequence koordinacije

Najveća prednost XRPL-a nije samo nizak transakcioni trošak. Prednost je to što veliki deo finansijske logike postoji kao deo protokola i prolazi kroz isti konsenzus, umesto da svaki tim ponovo implementira plaćanja, escrow, order book ili token kontrole u sopstvenom smart contractu.

Isti izbor je ujedno i ograničenje. Dobija se specijalizovan, relativno kompaktan model, ali ne i neograničena programabilnost. Zato XRPL najbolje funkcioniše kada se poslovni problem uklapa u njegove postojeće primitive, a off-chain sistem preuzima identitet, quoting, autorizaciju, računovodstvo i operativnu kontrolu.

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

TON Coin za developere: kako mreža zaista funkcioniše

Dora Milen — Fri, 18 Sep 2026 22:14:24 +0000

TON se često predstavlja kroz brzinu transakcija, Telegram integraciju i niske naknade. To jesu važne karakteristike, ali developeru ne objašnjavaju kako da napravi pouzdanu aplikaciju.

Pravo pitanje nije koliko transakcija mreža teoretski može da obradi, već kako se na TON-u modeluju stanje, izvršavanje i komunikacija između smart contracta.

Ako dolazite iz Ethereum ekosistema, najveća greška je da TON posmatrate kao EVM blockchain sa drugačijim adresama i jeftinijim gasom. TON nije EVM kompatibilna mreža, smart contracti ne koriste Solidity ABI, a složena operacija preko više contracta nije jedna velika sinhrona transakcija.

TON je distribuirani sistem u kojem nalozi razmenjuju asinhrone poruke. Ta odluka utiče na gotovo sve:

način projektovanja smart contracta
obradu grešaka i povratnih poruka
praćenje uplata
strukturu tokena
testiranje
backend arhitekturu
korisničko iskustvo

Tek kada se prihvati ovaj model, cells, Bag of Cells, traceovi, jetton walleti i bounce poruke prestaju da deluju kao nepovezane specifičnosti mreže.

TON, TON Coin i Gram nisu ista stvar

Pre tehničkih detalja treba razjasniti terminologiju.

TON, odnosno The Open Network, naziv je blockchain mreže.

Izvorna valuta mreže dugo je bila poznata kao Toncoin, TON Coin ili jednostavno TON. Aktuelni naziv valute je Gram, sa oznakom GRAM. Promena se odnosi na naziv, ticker i vizuelni identitet valute, ne na novu mrežu ili novi token koji bi korisnici morali da zamene.

Zbog kompatibilnosti, veliki deo postojećeg koda i dalje koristi stare tehničke nazive. U SDK-ovima ćete zato sretati:

toNano
nanoTON
AssetType.ton
pakete sa prefiksom @ton
polja, metode i komentare koji pominju TON kao valutu

To ne znači da koristite zastareli blockchain. Tehnički identifikatori ne menjaju se nužno istom brzin om kao naziv prikazan u walletu.

U nastavku teksta izraz TON Coin povremeno koristim kao prepoznatljiv naziv teme, dok se Gram odnosi na aktuelni naziv izvorne valute. U kodu treba pratiti konkretan SDK i njegove stvarne nazive, a ne ručno preimenovati metode koje još uvek koriste ton ili nanoTon.

Jedan GRAM deli se na milijardu najmanjih jedinica. Iznosi se zato čuvaju kao celi brojevi, ne kao floating-point vrednosti.

type GramAmount = bigint;

const oneGram: GramAmount = 1_000_000_000n;
const halfGram: GramAmount = 500_000_000n;

U JavaScriptu i TypeScriptu za blockchain iznose treba koristiti bigint ili decimalne stringove. Izraz poput 0.1 + 0.2 nije prihvatljiva osnova za finansijsku evidenciju.

Šta je TON iz ugla developera

TON je Layer 1 blockchain projektovan za horizontalno skaliranje. Smart contracti čuvaju stanje i izvršavaju kod u TON Virtual Machine okruženju, ali međusobno ne komuniciraju kao objekti unutar jednog procesa.

Oni razmenjuju poruke.

TON arhitektura može se posmatrati kroz tri nivoa:

masterchain
workchain
shardchain

Masterchain čuva globalnu konfiguraciju mreže, informacije potrebne za rad validatora, sistemske contracte i reference na poslednja prihvaćena stanja shardchainova.

Workchain predstavlja blockchain sa sopstvenim pravilima, formatima naloga i adresnim prostorom. Većina korisničkih naloga i aplikacionih contracta nalazi se u basechainu, čiji je workchain_id jednak 0.

Masterchain koristi workchain_id jednak -1.

Shardchainovi su delovi workchaina koji se obrađuju paralelno. Workchain može biti podeljen na više shardova kada opterećenje poraste, a shardovi se mogu ponovo spojiti kada dodatni kapacitet nije potreban.

Iz ugla aplikacije, račun ili smart contract pripada određenom workchainu i shardu. Kako se topologija shardova menja, contract ne dobija novu adresu niti aplikacija treba ručno da ga migrira.

Ovakva arhitektura omogućava mreži da raspodeli stanje i izvršavanje. Istovremeno, ona nameće pravilo da komunikacija između naloga mora biti asinhrona.

Contract A ne može pretpostaviti da će contract B završiti posao pre nego što se nastavi izvršavanje contracta A. Contract A može poslati poruku i završiti svoju transakciju. Contract B tu poruku obrađuje u posebnoj transakciji.

To je bliže actor modelu i distribuiranim servisima nego klasičnom pozivu funkcije.

Zašto je actor model važniji od brzine mreže

Zamislimo escrow aplikaciju.

Korisnik šalje sredstva escrow contractu. Escrow zatim treba da obavesti marketplace contract, koji proverava narudžbinu i šalje potvrdu. Nakon toga escrow oslobađa sredstva prodavcu.

Na sinhronom sistemu developer bi mogao da zamisli jednu operaciju:

escrow.deposit()
marketplace.confirm()
escrow.release()

Na TON-u se ovaj proces sastoji od više transakcija:

Wallet šalje internu poruku escrow contractu.
Escrow obrađuje poruku i menja svoje lokalno stanje.
Escrow šalje poruku marketplace contractu.
Marketplace obrađuje poruku.
Marketplace šalje potvrdu escrow contractu.
Escrow obrađuje potvrdu i šalje sredstva prodavcu.
Wallet prodavca prima transfer.

Sve ove transakcije zajedno čine širi tok koji se često posmatra kao trace.

Drugi korisnici i contracti mogu izvršavati sopstvene transakcije između pojedinih koraka. Zato escrow ne sme da pretpostavi da je njegovo stanje ostalo nepromenjeno dok je čekao odgovor.

Pouzdana implementacija bi čuvala nešto poput:

order_id
buyer
seller
amount
status
created_at
confirmation_deadline

Status bi mogao prolaziti kroz stanja:

created
funded
confirmation_pending
release_pending
released
refund_pending
refunded

Svaka primljena poruka mora proveriti da li je zahtev dozvoljen u trenutnom stanju.

Ovo je osnovni obrazac TON programiranja: smart contract je state machine, a poruke su događaji koji pokreću prelaze između stanja.

Nalog i smart contract su deo istog modela

Na TON-u svaki nalog ima adresu, balans i status. Aktivan nalog može imati kod i persistentne podatke, što ga čini smart contractom.

Tokom životnog ciklusa nalog može biti u jednom od četiri stanja:

nonexist
uninit
active
frozen

nonexist znači da nalog ne postoji u aktivnom stanju blockchaina. Nema balans, kod ni persistentne podatke.

uninit znači da adresa ima balans, ali smart contract još nije postavljen. Na takvu adresu moguće je unapred poslati sredstva.

active znači da su kod i početni podaci postavljeni i da contract može da obrađuje poruke.

frozen nastaje kada nalog ne može da izmiri naknade za čuvanje persistentnog stanja. Za ponovno aktiviranje potrebni su odgovarajući podaci i plaćanje duga, dok dovoljno veliki neizmireni dug može dovesti do uklanjanja naloga.

Ovaj model omogućava zanimljiv deployment workflow. Adresa contracta može se izračunati pre nego što je contract deployovan, jer se izvodi iz njegovog početnog stanja.

StateInit i determinističke adrese

StateInit opisuje početno stanje smart contracta. U praksi obuhvata njegov kod i početne podatke, uz dodatna protocol-level polja koja format podržava.

Adresa contracta izvodi se iz hash vrednosti njegovog početnog stanja i workchain identifikatora. To znači da developer može:

izračunati adresu pre deploymenta
prikazati je korisniku
poslati sredstva na nju
kasnije poslati deployment poruku sa odgovarajućim StateInit
proveriti da li se očekivani kod nalazi na očekivanoj adresi

Promena samo jednog bita početnog koda ili podataka proizvodi drugačiju adresu.

Ovo je korisno kod factory contracta, jetton walleta, NFT itema i drugih obrazaca gde se veliki broj naloga kreira deterministički.

Istovremeno, prefunding adrese nosi rizik. Ako aplikacija pogrešno izračuna StateInit, sredstva mogu završiti na adresi koja nikada neće biti aktivirana očekivanim kodom.

Zato logiku za računanje adrese ne treba kopirati na više mesta. Treba je staviti u isti wrapper koji se koristi za deployment, testiranje i slanje poruka.

Wallet na TON-u je smart contract

Wallet adresa nije isto što i javni ključ.

Wallet je smart contract koji proverava vlasništvo nad ključem, sprovodi replay zaštitu i šalje interne poruke drugim nalozima. Standardni wallet contract obično čuva:

javni ključ vlasnika
seqno
wallet_id ili subwallet_id
podatke specifične za verziju walleta

Privatni ključ ostaje van blockchaina.

Korisnik ili wallet aplikacija formiraju zahtev, potpisuju ga i šalju kao eksternu poruku wallet contractu. Contract proverava potpis i pravila zahteva, a zatim generiše interne poruke.

Wallet ne čuva sopstveni balans kao običnu promenljivu. Balans je deo protocol-level stanja naloga i validatori ga ažuriraju kada sredstva stignu, budu poslata ili potrošena na naknade.

seqno je brojač koji sprečava ponovno izvršavanje iste potpisane poruke. Wallet prihvata očekivanu vrednost i nakon uspešne obrade povećava brojač.

valid_until ograničava trajanje zahteva. Potpisana poruka koja nije uključena u mrežu pre isteka ne bi trebalo da ostane zauvek validna.

wallet_id razdvaja različite wallet instance koje mogu koristiti isti javni ključ. Zbog toga isti mnemonic ili public key ne moraju proizvesti istu adresu za svaku verziju wallet contracta, mrežu ili subwallet konfiguraciju.

Backend koji generiše wallet adrese mora zato eksplicitno znati:

verziju wallet contracta
mrežu
wallet_id
workchain
javni ključ

Pretpostavka da je adresa samo hash javnog ključa dovodi do pogrešnih adresa i potencijalnog gubitka sredstava.

Eksterne i interne poruke

TON koristi tri osnovne kategorije poruka:

incoming external messages
internal messages
outgoing external messages

Incoming external message dolazi izvan blockchaina. Tipičan primer je zahtev koji wallet aplikacija šalje wallet contractu.

Takva poruka ne može da donese Gram iz spoljnog sveta. Contract koji je prihvati može trošak izvršavanja platiti iz sopstvenog balansa.

Internal message šalje jedan blockchain nalog drugom. Ona može sadržati:

adresu primaoca
prenetu vrednost
telo poruke
opcioni StateInit
bounce podešavanje
parametre relevantne za prosleđivanje

Outgoing external message izlazi iz blockchain okruženja i može služiti kao događaj namenjen spoljnim servisima i indexerima.

Za većinu dApp tokova najvažnije su eksterne poruke ka walletima i interne poruke između contracta.

Eksterna poruka obično pokreće wallet, a wallet zatim šalje internu poruku dApp contractu.

Poruka nije transakcija

Ova razlika je važna za praćenje uplata.

Poruka predstavlja zahtev ili nameru. Transakcija je rezultat obrade poruke na određenom nalogu.

Ako korisnik potpiše zahtev u walletu, to još uvek ne znači da je poslovna operacija završena. Čak ni pojavljivanje prve wallet transakcije ne znači da je svaki contract u traceu uspešno izvršio svoj deo posla.

Na primer, wallet transakcija može uspešno poslati tri interne poruke. Jedna od njih može biti obrađena, druga odbijena, a treća vraćena kroz bounce.

TON Connect može vratiti BoC potpisane eksterne poruke, ali taj odgovor nije dokaz da je primalac uspešno obradio transfer. Rezultat treba pronaći i proveriti on-chain.

Pouzdan statusni model na backendu može izgledati ovako:

created
awaiting_signature
submitted
observed
processing
confirmed
failed
expired

submitted znači da je zahtev potpisan ili prosleđen.

observed znači da je odgovarajuća transakcija pronađena na mreži.

confirmed treba koristiti tek kada su provereni relevantni primaoci, iznosi, payload, statusi transakcija i očekivani ishod tracea.

Faze TON transakcije

Obična TON transakcija ne sastoji se samo od pokretanja contract koda. Obrada prolazi kroz više faza.

Relevantne faze su:

storage
credit
compute
action
bounce

Tačan redosled zavisi od karakteristika poruke, uključujući bounce podešavanje.

U storage fazi obračunavaju se troškovi čuvanja stanja naloga.

U credit fazi vrednost dolazne interne poruke pripisuje se nalogu.

U compute fazi TVM izvršava contract kod.

U action fazi mreža obrađuje akcije koje je contract pripremio tokom izvršavanja. To mogu biti slanje poruke, rezervisanje sredstava, promena koda ili rad sa bibliotekama.

U bounce fazi može se formirati povratna poruka kada obrada ne uspe pod uslovima koji dozvoljavaju bounce.

Compute faza i action faza nisu ista stvar.

Contract može uspešno završiti računanje i pripremiti izlazne poruke, ali neka izlazna akcija ipak može biti neuspešna. Zato test koji proverava samo TVM exit code ne mora dokazivati da je poslovni tok uspeo.

Za svaku važnu operaciju treba proveriti:

da li je transakcija aborted
compute exit code
action result code
broj kreiranih poruka
primaoce poruka
prenete iznose
bounce poruke
završno stanje contracta
nastavak tracea

Šta su send modes

Kada contract šalje internu poruku, send mode određuje kako se vrednost i greške tretiraju.

Različiti modovi i zastavice mogu uticati na to:

da li se naknade plaćaju odvojeno
da li poruka prenosi preostalu vrednost primljene poruke
da li se šalje preostali balans contracta
da li se pojedine greške ignorišu
da li neuspeh akcije treba da izazove bounce
da li se nalog uklanja ako balans postane nula

Send mode nije detalj koji treba nasumično kopirati iz primera.

Posebno su opasni modovi koji ignorišu greške. Oni mogu biti opravdani u određenom protokolarnom toku, ali mogu i proizvesti situaciju u kojoj početna transakcija izgleda uspešno, dok očekivana izlazna poruka nije poslata.

Svaki send mode treba posmatrati kao deo poslovne semantike contracta, a ne samo optimizaciju naknade.

Bounce nije globalni rollback

Bounce poruka obaveštava pošiljaoca da primalac nije obradio poruku kako je očekivano. Ona može vratiti deo preostale vrednosti i podatke koji omogućavaju povezivanje sa prvobitnim zahtevom.

To nije globalni rollback kompletnog tracea.

Ako je contract A promenio svoje stanje i poslao poruku contractu B, neuspeh contracta B ne mora automatski vratiti contract A u prethodno stanje.

Contract A zato treba eksplicitno da podrži kompenzacioni tok.

Primer:

Contract A primi zahtev za isplatu.
Contract A označi zahtev kao pending.
Contract A pošalje sredstva contractu B.
Ako obrada uspe, A kasnije dobija potvrdu ili se ishod verifikuje kroz očekivani tok.
Ako poruka bude vraćena, A obrađuje bounce i vraća zahtev u available ili failed stanje.

Loš obrazac je smanjiti korisnički balans, poslati poruku i ne implementirati bounce handler. U slučaju neuspeha sredstva se možda vrate contractu, ali interna evidencija korisnika ostaje pogrešna.

Za povezivanje zahteva i odgovora često se koristi query_id. On treba da bude dovoljno jedinstven u domenu contracta i vezan za zapis operacije koja je u toku.

Cells su osnovni format podataka

TON ne čuva persistentno stanje kao proizvoljan niz bajtova niti koristi klasičan ABI model identičan EVM-u.

Osnovna jedinica podataka je cell.

Jedna cell može sadržati:

najviše 1023 bita podataka
najviše četiri reference na druge cells

Reference formiraju usmereni aciklični graf. Ciklične reference nisu dozvoljene.

Cells se koriste za:

smart contract kod
persistentne podatke
tela poruka
StateInit
transakcije
blokove
Merkle dokaze
dictionaries

Ograničenje od 1023 bita ne znači da poruka ili contract mogu imati samo toliko podataka. Veće strukture se dele kroz reference ka drugim cells.

Ipak, raspored podataka utiče na cenu. Više cells i referenci može povećati storage i forwarding naknade.

Developer zato mora razmišljati o binarnom layoutu, ne samo o logičkoj strukturi objekta.

Builder, Cell i Slice

Pri radu sa cells često se koriste tri mentalna modela.

Builder služi za kreiranje cell strukture. U njega se upisuju bitovi, brojevi, adrese, token iznosi i reference.

Cell predstavlja završenu strukturu.

Slice predstavlja cursor za čitanje sadržaja cella.

Jednostavan komentar ili identifikator fakture može se napraviti pomoću @ton/core paketa:

import { beginCell, Cell } from "@ton/core";

function createInvoicePayload(invoiceId: string): Cell {
    return beginCell()
        .storeUint(0, 32)
        .storeStringTail(`invoice:${invoiceId}`)
        .endCell();
}

Nulti 32-bitni prefiks koristi se kao konvencija za tekstualni komentar. Primalac zatim ostatak sadržaja može čitati kao UTF-8 string.

Za contract protokol je obično bolji strukturirani binarni payload:

import { beginCell, Cell } from "@ton/core";

function createPaymentPayload(
    queryId: bigint,
    invoiceNumber: bigint,
): Cell {
    return beginCell()
        .storeUint(0x70617901, 32)
        .storeUint(queryId, 64)
        .storeUint(invoiceNumber, 64)
        .endCell();
}

Ovde je 0x70617901 aplikacioni opcode. Vrednost opkoda treba dokumentovati i držati stabilnom nakon objave protokola.

Contract mora čitati polja istim redosledom i istom širinom:

opcode kao 32-bitni unsigned integer
queryId kao 64-bitni unsigned integer
invoiceNumber kao 64-bitni unsigned integer

Ako serializer piše uint64, a parser očekuje uint32, protokol je pokvaren čak i kada se obe strane kompajliraju bez greške.

Bag of Cells i BoC

Stablo cells se pri prenosu ili čuvanju serijalizuje kao Bag of Cells, odnosno BoC.

BoC se često pojavljuje kao:

base64 string u API odgovoru
binarni deployment artifact
rezultat koji vraća TON Connect
serijalizovano telo poruke
ulaz za emulaciju transakcije
dokaz stanja ili transakcije

BoC može sadržati više root cells. Interno može eliminisati duplikate, jer se cells sa istim hashom mogu deliti između više grana grafa.

Kada TON Connect vrati result.boc, ne vraća JSON opis uspešnog transfera. Vraća serijalizovanu eksternu poruku koju treba povezati sa stvarnim on-chain transakcijama.

Backend ili indexer zato mora znati kako da:

izračuna hash poruke
pronađe transakciju koja ju je obradila
prati izlazne interne poruke
dekodira njihova tela
proveri kompletan ishod

TL-B je deo javnog interfejsa

TL-B je jezik šema koji TON koristi za opis binarnih struktura.

Njime su opisani:

blokovi
transakcije
poruke
adrese
StateInit
currency collections
standardni token interfejsi

U Solidity svetu ABI često daje gotov opis funkcija i tipova. Na TON-u je TL-B šema bliža preciznom wire protocolu.

Jetton transfer, na primer, nije poziv metode u klasičnom smislu. To je cell čiji sadržaj prati standardizovani TL-B raspored.

Zato dokumentacija smart contracta treba da sadrži najmanje:

opcode svake poruke
raspored polja
bit width brojeva
da li se podatak čuva inline ili u referenci
semantiku query_id
očekivanu vrednost poruke
bounce ponašanje
moguće exit kodove
očekivane izlazne poruke

Binarna šema je API contracta. Njena promena bez plana kompatibilnosti jednaka je breaking promeni HTTP API-ja.

TON Virtual Machine

TON Virtual Machine je stack-based virtuelna mašina koja izvršava smart contract kod i ima ugrađene operacije za rad sa cells, slices, builders, dictionaries i kriptografskim funkcijama.

Persistentno stanje contracta ulazi u izvršavanje kao cell. Nakon uspešnog izvršavanja nova vrednost persistentnog stanja može biti sačuvana.

Contract tokom compute faze formira listu akcija. U action fazi mreža izvršava te akcije.

Među protocol-level akcijama nalaze se:

slanje poruke
rezervisanje sredstava
promena koda
rad sa bibliotekama

Jedna transakcija može pripremiti najviše 255 akcija.

Get metode se izvršavaju drugačije. One se pokreću lokalno preko nodea ili providera, ne menjaju blockchain stanje i korisnik ne šalje on-chain transakciju samo da bi pročitao rezultat.

To ih čini pogodnim za:

čitanje konfiguracije contracta
prikaz stanja u frontendu
dobijanje token podataka
računanje determinističke adrese
proveru vlasništva
dobijanje seqno vrednosti walleta

Drugi smart contract ne može jednostavno sinhrono pozvati get metodu drugog contracta. On-chain komunikacija i dalje se odvija porukama.

Jezici i razvojni alati

Zvanični jezik za nove TON smart contracte je Tolk. FunC ostaje važan zbog velikog broja postojećih contracta i biblioteka, ali se tretira kao legacy put za održavanje starijeg koda.

U ekosistemu se koristi i Tact, posebno za projekte kojima odgovara viši nivo apstrakcije. Izbor jezika treba zasnovati na:

zrelosti toolchaina
dostupnosti biblioteka
iskustvu tima
potrebi za kontrolom nad serijalizacijom
zahtevima audita
kompatibilnosti sa postojećim contractima

Za TypeScript orijentisan razvoj često se koristi Blueprint. Osnovni workflow uključuje generisanje projekta, build, lokalno testiranje, deployment skripte i wrappere.

npm create ton@latest
cd example-project
npm install

npx blueprint build
npx blueprint test

Tačan interaktivni izbor templatea i jezika zavisi od verzije alata. Komande, nazive templatea i konfiguraciju ne treba prepisivati iz starog blog posta bez poređenja sa dokumentacijom instalirane verzije.

Wrapper je posebno važan deo TON projekta. On na jednom mestu treba da sadrži:

izračunavanje adrese
kreiranje StateInit
serijalizaciju poruka
parsiranje get metoda
deployment logiku
TypeScript tipove
helper metode za testove i skripte

Dobar wrapper sprečava da frontend, backend i deployment skripta svako na svoj način formiraju isti cell.

Kako treba testirati TON contract

Unit test koji pozove handler i proveri jednu promenljivu nije dovoljan.

TON contract treba testirati kroz poruke i njihove posledice. Sandbox test treba da proveri kompletan skup transakcija koje su nastale tokom tracea.

Koristan test proverava:

pošiljaoca ulazne poruke
primaoca
bounce flag
vrednost poruke
opcode
exit code
action status
izlazne poruke
njihove vrednosti i payload
završno persistentno stanje
promenu balansa
vraćene excess poruke
bounce obradu

Obavezni negativni testovi uključuju:

poruku od neovlašćenog pošiljaoca
duplirani query_id
nepoznat opcode
premalo priložene vrednosti
malformed cell
pogrešnu adresu
pogrešan workchain
bounce očekivane izlazne poruke
paralelne operacije nad istim stanjem
pokušaj ponavljanja eksterne poruke
ekstremne granične vrednosti

Za debugging treba posmatrati ceo trace. Ako prva transakcija prođe, a poslednja ne promeni očekivano stanje, problem se često nalazi u poruci između njih, nedovoljnoj vrednosti ili action fazi.

TON Connect povezuje aplikaciju i wallet

TON Connect je standardni protokol za povezivanje dApp-a sa TON walletima.

On aplikaciji omogućava da:

dobije adresu izabranog walleta
zatraži dokaz kontrole nad adresom
zatraži potpis
pošalje zahtev za transakciju
obnovi postojeću sesiju

Aplikacija pritom ne dobija privatni ključ korisnika.

TON Connect koristi dApp, wallet i bridge. Bridge prenosi end-to-end šifrovane poruke i ne treba da ima pristup njihovom otvorenom sadržaju.

Za React aplikacije koristi se @tonconnect/ui-react:

npm install @tonconnect/ui-react

Aplikacija mora imati javno dostupan manifest:

{
  "url": "https://example.com",
  "name": "Example App",
  "iconUrl": "https://example.com/icon-180.png"
}

Manifest treba da bude dostupan preko HTTPS-a, bez autentifikacije, CORS blokade ili proxy challenge stranice. Wallet ga koristi da korisniku prikaže identitet aplikacije.

Provider se zatim postavlja oko React aplikacije:

"use client";

import {
    TonConnectButton,
    TonConnectUIProvider,
} from "@tonconnect/ui-react";

export function Providers({
    children,
}: {
    children: React.ReactNode;
}) {
    return (
        <TonConnectUIProvider
            manifestUrl={
                "https://example.com/tonconnect-manifest.json"
            }
        >
            <TonConnectButton />
            {children}
        </TonConnectUIProvider>
    );
}

Kod Next.js App Router aplikacije provider mora biti u client komponenti, jer SDK koristi browser funkcionalnosti poput lokalnog storagea i modala.

Slanje transakcije preko TON Connecta

TON Connect sendTransaction prima zahtev sa rokom važenja i jednom ili više poruka.

"use client";

import { beginCell, toNano } from "@ton/core";
import {
    useTonConnectUI,
    useTonWallet,
} from "@tonconnect/ui-react";

export function PaymentButton({
    recipient,
    invoiceId,
}: {
    recipient: string;
    invoiceId: string;
}) {
    const wallet = useTonWallet();
    const [tonConnectUi] = useTonConnectUI();

    async function pay() {
        const payload = beginCell()
            .storeUint(0, 32)
            .storeStringTail(`invoice:${invoiceId}`)
            .endCell();

        const result = await tonConnectUi.sendTransaction({
            validUntil: Math.floor(Date.now() / 1000) + 300,
            network: "-239",
            messages: [
                {
                    address: recipient,
                    amount: toNano("0.05").toString(),
                    payload: payload.toBoc().toString("base64"),
                },
            ],
        });

        console.log(result.boc);
    }

    return (
        <button disabled={!wallet} onClick={pay}>
            Potvrdi plaćanje
        </button>
    );
}

network vrednost -239 označava mainnet, dok se za testnet koristi -3.[14]

Iznos se šalje kao decimalni string najmanjih jedinica. Payload je base64 kodiran BoC.

Ovaj kod inicira wallet tok, ali ne treba da aktivira proizvod odmah nakon što sendTransaction vrati rezultat. Vraćeni BoC treba sačuvati kao podatak za praćenje, a uplatu potvrditi nakon provere blockchaina.

Takođe, više poruka u jednom wallet zahtevu nisu jedna atomska operacija na svim primaocima. Wallet može potpisati i poslati paket, ali svaki primalac obrađuje svoju poruku nezavisno. Jedna može uspeti, a druga pasti.

ton_proof za autentifikaciju

Povezana wallet adresa sama po sebi nije dovoljna za backend login.

Frontend može backendu poslati bilo koju adresu kao string. Backend mora dobiti kriptografski dokaz da korisnik kontroliše odgovarajući wallet.

TON Connect za to koristi ton_proof.

Tipičan tok izgleda ovako:

Backend generiše jednokratni nonce.
Nonce se vezuje za sesiju, domen i rok važenja.
Frontend zahteva ton_proof prilikom povezivanja walleta.
Wallet potpisuje strukturiranu poruku.
Frontend šalje proof backendu.
Backend proverava payload, domen, timestamp, adresu, StateInit, javni ključ i Ed25519 potpis.
Nonce se označava kao iskorišćen.
Backend izdaje sopstvenu aplikacionu sesiju.

Potpis je vezan za wallet adresu, domen aplikacije, vreme i payload. Time se smanjuje rizik da proof napravljen za jednu aplikaciju bude iskorišćen na drugom domenu.

Javni ključ iz odgovora ne treba slepo prihvatiti. Backend treba da proveri njegovu vezu sa wallet adresom i StateInit, ili da koristi odgovarajući on-chain metod kada je potrebno.

Nonce mora biti:

kriptografski nasumičan
kratkog roka
vezan za konkretnu sesiju
neupotrebljiv nakon prve uspešne provere

ton_proof potvrđuje kontrolu nad walletom. Ne potvrđuje da korisnik poseduje određeni token, da je izvršio uplatu ili da je konkretna transakcija uspešna. To su odvojene provere.

Realan payment workflow

Zamislimo Telegram Mini App koji prodaje digitalnu uslugu.

Korisnik bira paket i plaća izvorном valutom mreže. Pouzdan sistem treba da razdvoji kreiranje narudžbine, potpisivanje i blockchain potvrdu.

Backend prvo kreira invoice:

{
  "invoiceId": "inv_8d712",
  "userId": "usr_184",
  "asset": "GRAM",
  "amountNano": "50000000",
  "recipient": "UQ...",
  "status": "created",
  "expiresAt": 1760000000
}

Vreme u primeru je samo Unix vrednost u podacima, ne hardkodovana poslovna konstanta.

Backend zatim vraća frontendu:

adresu primaoca
tačan iznos u najmanjim jedinicama
payload sa invoice identifikatorom
dozvoljenu mrežu
rok važenja zahteva

Frontend ne bi trebalo sam da odlučuje koliko treba platiti i kome. U suprotnom korisnik ili izmenjeni klijent mogu promeniti parametre pre otvaranja walleta.

Nakon potpisa backend prati mrežu i proverava:

da li je primalac tačan
da li je asset tačan
da li je iznos dovoljan
da li payload sadrži očekivani invoice ID
da li invoice postoji
da li je invoice još validan
da li uplata već nije obrađena
da li je relevantna transakcija uspešna
da li postoji neočekivani bounce
da li je trace dostigao očekivano završno stanje

Tek tada se invoice označava kao plaćen.

Idempotency nije opcioni detalj

Blockchain event može biti obrađen više puta.

Razlozi uključuju:

restart workera
ponovni API zahtev
preklapanje pollinga i streama
retry nakon timeouta
ponovno indeksiranje
ručni reconciliation
duplirani webhook

Backend zato mora imati stabilan identitet uplate.

To može biti kombinacija:

account_address
transaction_lt
transaction_hash
message_hash

Ili jedinstveni aplikacioni identifikator povezan sa verifikovanom transakcijom.

Baza treba da ima unique constraint koji sprečava dvostruko kreditiranje.

CREATE UNIQUE INDEX payments_chain_identity_unique
ON payments (
    network,
    account_address,
    transaction_lt,
    transaction_hash
);

Business handler zatim treba da bude idempotentan:

begin transaction

insert payment if not exists

if payment already processed:
    return previous result

mark invoice as paid
grant purchased entitlement
mark payment as processed

commit

Bez ovoga, savršeno validna blockchain integracija može napraviti duplu internu uplatu zbog običnog backend retryja.

Kako čitati TON blockchain

DApp obično ne komunicira direktno sa validatorima iz browsera. Koriste se API provideri, liteserveri i indeksirani data servisi.

TON Center API v3 predstavlja indeksirani sloj koji omogućava pretragu:

transakcija
poruka
traceova
akcija
jetton transfera
NFT podataka
istorijskih događaja

Postoje endpointi za pronalaženje transakcija na osnovu message hasha i za čitanje dekodiranih akcija.

Indexirani API je praktičan, ali uvodi poverenje u provider. Provider može kasniti, pogrešno dekodirati podatke ili biti nedostupan.

Za kritičnije sisteme mogu se koristiti:

sopstveni full node
liteserver
archive infrastruktura
sopstveni indexer
provera Merkle dokaza
kombinacija više nezavisnih providera

Full node i archive node nisu ista stvar. Full node može čuvati aktuelno stanje i novije blokove uz pruning, dok je archive infrastruktura potrebna kada servis mora pouzdano da pretražuje kompletnu istoriju.

Razuman produkcioni kompromis često izgleda ovako:

Primarni indexed API za brzo čitanje.
Drugi provider za proveru kritičnih podataka.
Lokalna baza sa sopstvenim cursorom.
Periodični reconciliation starijih transakcija.
Alert kada indexer lag pređe dozvoljeni prag.
Mogućnost ponovne obrade određenog raspona blokova.

Jettoni nisu centralizovani ERC-20 mapping

Fungibilni tokeni na TON-u nazivaju se jettons. Standardni interfejs opisan je kroz TEP-74.

Kod tipičnog ERC-20 contracta jedan contract čuva mapping svih adresa i balansa.

Kod jettona se koriste:

jetton master contract
pojedinačni jetton wallet contracti

Master contract čuva opšte podatke o tokenu, kao što su ukupna ponuda, metadata i kod wallet contracta.

Svaki vlasnik ima sopstveni jetton wallet contract za konkretan jetton.

Ako token ima tri vlasnika, u jednostavnom modelu postoje jedan master i tri jetton wallet contracta.

Jetton transfer zato nije samo promena dva polja u jednom centralnom mappingu. Tipičan tok uključuje:

Korisnikov običan wallet šalje poruku njegovom jetton walletu.
Pošiljaočev jetton wallet smanjuje balans.
On šalje internu transfer poruku jetton walletu primaoca.
Primaočev jetton wallet povećava balans.
Po potrebi se šalje transfer_notification krajnjem primaocu.
Višak izvorne valute vraća se kroz excesses poruku.

Ako primaočev jetton wallet još ne postoji, može biti deterministički deployovan tokom transfera.

Ovaj model raspoređuje stanje i izvršavanje između više contracta, što se uklapa u sharding arhitekturu TON-a. Cena je složenija integracija.

Bezbedna obrada jetton uplata

Naziv, simbol i slika jettona nisu dokaz identiteta.

Napadač može napraviti token sa istim nazivom i logotipom kao poznati stablecoin. Aplikacija koja proverava samo metadata podatke može prihvatiti bezvredni lažni token.

Pouzdana integracija održava allowlist jetton master adresa.

Kada servis primi transfer_notification, treba proveriti:

opcode 0x7362d09c
adresu contracta koji je poslao poruku
vezu između tog jetton walleta i odobrenog mastera
vlasnika očekivanog jetton walleta
iznos u osnovnim jedinicama
query_id
originalnog pošiljaoca
forward_payload
bounce indikatore
neočekivane izlazne poruke

Odnos mastera i walleta proverava se korišćenjem standardnog get_wallet_address() metoda na pouzdanom jetton master contractu. Dobijena adresa mora odgovarati jetton walletu koji je poslao notifikaciju.

TEP-74 definiše standardne poruke, uključujući:

transfer
internal_transfer
transfer_notification
excesses
burn
burn_notification

transfer_notification se šalje samo ako je forward_ton_amount veći od nule. Servisi koji zavise od notifikacije moraju to uzeti u obzir pri formiranju transfera.

Jetton iznosi takođe nisu nužno u devet decimala. Broj decimala zavisi od konkretnog tokena. Backend mora čuvati integer količinu i zasebno metadata informaciju potrebnu za prikaz.

Koliko košta TON transakcija

TON nema jednu fiksnu naknadu za svaku transakciju.

Ukupan trošak može uključiti:

storage fee
compute fee
import fee
action fee
forward fee

Storage fee zavisi od količine persistentnih podataka i vremena tokom kojeg se čuvaju.

Compute fee zavisi od potrošenog TVM gasa.

Import fee odnosi se na obradu ulazne eksterne poruke.

Action i forward fee zavise od izlaznih akcija, veličine poruka, broja cells i njihovog prosleđivanja.

Zbog toga jednostavan transfer, deployment contracta i jetton transfer nemaju isti trošak.

Jetton transfer može uključiti više contracta i poruka:

wallet
sender jetton wallet
receiver jetton wallet
recipient
response destination

Svaki dodatni korak može imati sopstveni compute i forwarding trošak.

Naknada zavisi i od konfiguracionih parametara mreže. Vrednosti se mogu menjati, pa ih ne treba trajno hardkodovati u poslovnu logiku.

Praktičan pristup je:

Izgraditi tačnu poruku.
Emulirati ili proceniti transakciju preko pouzdanog providera.
Dodati razumnu rezervu.
Nakon izvršenja pročitati stvarno potrošene naknade.
Pratiti odstupanje procene od realnog troška.

Za aplikaciju je često važniji maksimalni dozvoljeni trošak operacije nego prosečna naknada.

Ako ugovor mora da pošalje četiri izlazne poruke, treba dokazati da priložena vrednost pokriva najgori podržani slučaj, ne samo srećnu putanju iz jednog testa.

Storage nije besplatan posle deploymenta

Smart contract nije datoteka koja se jednom uploaduje i zatim zauvek ostaje bez troška.

Persistentni kod i podaci imaju storage cenu. Ako contract čuva sve veći dictionary korisnika, narudžbina ili istorijskih događaja, trošak može rasti tokom vremena.

Zato nije dobro automatski čuvati svaki događaj on-chain.

Primeri podataka koji često ne moraju biti u persistentnom contract stanju:

kompletna istorija promena
analitički podaci
pretraživi tekst
korisnički profili
logovi
podaci koji se mogu rekonstruisati iz transakcija
privatne informacije
veliki metadata dokumenti

On-chain treba čuvati minimalno stanje potrebno za verifikaciju i sprovođenje pravila.

Umesto kompletne liste dokumenata, contract može čuvati Merkle root. Umesto istorije svih statusa, može čuvati samo trenutno stanje i emitovati događaje za indexer.

Konsenzus, finalnost i šta aplikacija zapravo čeka

TON koristi Proof-of-Stake. Validatori učestvuju u predlaganju i potvrđivanju blokova, dok masterchain daje zajednički pogled na stanje shardchainova.

Dokumentacija opisuje finalnost koja se u uobičajenim uslovima postiže ispod jedne sekunde. To treba posmatrati kao karakteristiku protokola, ne kao garantovani application-level SLA.

Korisnik može ipak čekati duže zbog:

wallet UI-ja
slanja preko bridgea
API pollinga
indexer laga
obrade tracea sa više poruka
backend queuea
baze podataka
retry politike

Ako frontend proverava status jednom u deset sekundi, mrežna finalnost ispod sekunde neće proizvesti brz korisnički doživljaj.

Produkcioni sistem treba da meri najmanje:

wallet_signed_at
submitted_at
first_seen_at
included_at
business_confirmed_at

Tako se može utvrditi da li usporenje dolazi iz walleta, providera, indexera ili sopstvenog backenda.

Bezbednost eksternih poruka

Incoming external message ne donosi sredstva contractu. Contract ima ograničen gas credit da proveri zahtev pre nego što prihvati plaćanje daljeg izvršavanja iz sopstvenog balansa.

Ako contract prerano izvrši ACCEPT, napadač može ponavljati nevalidne zahteve i trošiti njegov balans.

Pre prihvatanja eksterne poruke obično treba proveriti:

potpis
seqno
valid_until
wallet_id
očekivani format
domen ili kontekst potpisa
dozvoljenu operaciju

Nakon uspešne provere contract može prihvatiti poruku i promeniti stanje.

Nedostatak replay zaštite je posebno opasan. Validno potpisan zahtev ne sme moći da se izvrši više puta.

Za većinu dApp contracta jednostavniji i sigurniji model je da primaju interne poruke iz standardnog walleta, umesto da samostalno implementiraju složenu obradu eksternih potpisa.

Adrese, bounceable format i validacija

TON adresa može biti prikazana u raw ili user-friendly formatu.

Raw oblik izgleda kao workchain i 256-bitni identifikator:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

User-friendly format uključuje dodatne zastavice i checksum. Može označiti da li je adresa bounceable i da li pripada test mreži.

Različiti tekstualni oblici mogu predstavljati isti underlying nalog.

Backend zato ne treba da poredi adrese običnim poređenjem originalnih stringova. Potrebno ih je parsirati i normalizovati pomoću proverene biblioteke.

import { Address } from "@ton/core";

const first = Address.parse(inputAddress);
const second = Address.parse(storedAddress);

const sameAccount = first.equals(second);

Treba proveriti i workchain. Aplikacija koja očekuje basechain nalog ne bi trebalo da prihvati proizvoljnu adresu bez provere.

Bounceable adresa je prikladna kada se očekuje aktivan contract i kada pošiljalac želi povratnu poruku u slučaju neuspeha.

Non-bounceable format je često prikladniji za prvi transfer ka još nedeployovanoj wallet adresi. To nije univerzalno pravilo za svaki protokol, već deo odluke o očekivanom stanju primaoca.

Zašto kompletan backend i dalje ostaje potreban

TON ne uklanja potrebu za klasičnim backendom.

Blockchain dobro rešava:

javno proverljivo vlasništvo
prenos vrednosti
zajedničko stanje između nepouzdanih strana
pravila koja ne zavise od jednog servera
transparentnu evidenciju izvršenja

Klasičan backend je obično bolji za:

pretragu
analitiku
privatne podatke
email i push obaveštenja
rate limiting
preporuke
moderaciju
korisničku podršku
kompleksne izveštaje
brzo keširanje
poslovne integracije

Najzdravija arhitektura nije „sve on-chain“, već jasna podela odgovornosti.

Smart contract treba da bude mali, determinističan i proverljiv. Backend treba da indeksira događaje, održava aplikacione projekcije, prati neuspešne tokove i pruža korisniku razumljiv interfejs.

Predložena arhitektura produkcione aplikacije

Za ozbiljniji TON proizvod razumno je odvojiti nekoliko komponenti.

Frontend ili Mini App prikazuje korisnički interfejs i koristi TON Connect za wallet sesiju.

Application backend upravlja korisnicima, invoiceima, dozvolama i poslovnom logikom koja ne mora biti on-chain.

Transaction builder formira očekivane poruke i payload. Za finansijske operacije često je sigurnije da backend napravi parametre nego da ih frontend slobodno sastavlja.

Blockchain listener prati naloge, transakcije, poruke i traceove.

Decoder parsira standardne i aplikacione TL-B poruke.

Reconciliation worker ponovo proverava nepotvrđene i ranije obrađene transakcije.

Database čuva raw blockchain identitete, dekodirane događaje i aplikacione projekcije.

Smart contract wrapper obezbeđuje isti binarni format u testovima, skriptama i aplikacionom kodu.

Tok može izgledati ovako:

flowchart LR
    U[Korisnik] --> F[Frontend ili Mini App]
    F --> TC[TON Connect]
    TC --> W[Wallet]
    W --> N[TON mreža]
    F --> B[Application backend]
    B --> D[(Baza)]
    N --> I[Indexer ili liteserver]
    I --> L[Blockchain listener]
    L --> V[Validator poslovnih pravila]
    V --> D
    D --> R[Reconciliation worker]
    R --> I

Ključna tačka je da wallet odgovor i blockchain potvrda ulaze u sistem različitim putem. Frontend inicira nameru, dok listener potvrđuje izvršenje.

Gde TON ima praktičnog smisla

TON je posebno zanimljiv kada aplikacija ima prirodnu vezu sa Telegram okruženjem ili zahteva veliki broj relativno nezavisnih on-chain interakcija.

Primeri uključuju:

plaćanja u Telegram Mini Apps aplikacijama
digitalnu robu
pretplate
nagrade i loyalty programe
igre sa digitalnim vlasništvom
marketplace tokove
escrow contracte
NFT kolekcije
community tokene
mikroplaćanja
DeFi protokole
servise sa mnogo pojedinačnih korisničkih stanja

To ne znači da svaki Telegram bot treba blockchain.

Ako proizvod ima jednog operatera, nema potrebu za javno proverljivim vlasništvom i sve transakcije se mogu pouzdano voditi u običnoj bazi, blockchain može dodati više složenosti nego vrednosti.

TON ima smisla kada su javno vlasništvo, prenosiva sredstva, interoperabilnost i izvršavanje bez centralnog posrednika stvarni deo proizvoda.

Glavni trade-offi

TON-ov sharding i message-driven model omogućavaju horizontalno skaliranje, ali prenose deo složenosti na aplikacionu arhitekturu.

Asinhronost otežava višekoračne operacije. Potrebni su statusi, query_id, bounce handleri i kompenzacione akcije.

Binarna serijalizacija traži disciplinu. Cell koji je pogrešno pročitan za jedan bit može potpuno promeniti značenje poruke.

Jetton model povećava broj contracta. Distribuirano stanje olakšava skaliranje, ali transfer više nije promena jednog centralnog mappinga.

Indexer postaje važan deo proizvoda. Korisnik ne želi da ručno pregleda block explorer kako bi saznao zašto uplata nije prepoznata.

Provider ubrzava razvoj, ali uvodi poverenje. Sopstveni node smanjuje zavisnost, ali povećava operativni trošak.

Brza finalnost ne rešava spor backend. Observability i event processing ostaju odgovornost aplikacije.

Niske naknade nisu isto što i neograničeno besplatno stanje. Storage, broj poruka i veličina payload-a i dalje imaju cenu.

Telegram distribucija može postati platformska zavisnost. Blockchain domen i poslovnu logiku treba odvojiti od konkretnog Mini App interfejsa.

Kako bih procenjivao TON za novi projekat

Pre izbora mreže postavio bih nekoliko praktičnih pitanja.

Da li proizvod dobija konkretnu vrednost iz TON wallet i Telegram ekosistema?

Da li se poslovni proces može modelovati kao asinhrona state machine?

Da li tim razume da jedan korisnički zahtev može proizvesti više blockchain transakcija?

Da li postoji plan za bounce, retry, timeout i reconciliation?

Da li se svi finansijski iznosi čuvaju u najmanjim jedinicama?

Da li smart contract može ostati dovoljno mali da bude temeljno testiran i auditovan?

Da li postoji jasan razlog zbog kojeg određeni podatak mora biti on-chain?

Da li tim može da održava indexer ili pouzdano upravlja eksternim providerom?

Da li je korisničko iskustvo prihvatljivo kada wallet ili provider privremeno nisu dostupni?

Ako su odgovori pozitivni, TON može biti dobar izbor za aplikacije koje zahtevaju veliki broj brzih transfera, distribuirano vlasništvo i prirodnu integraciju sa walletima.

Ako aplikacija zahteva velike sinhrone operacije preko mnogo contracta, intenzivno privatno računanje ili čuvanje velike količine podataka, klasičan backend ili drugačiji blockchain model mogu biti jednostavniji.

Najvažnije je ne birati TON samo na osnovu jedne brojke o brzini ili prosečnoj naknadi.

Njegova prava tehnička vrednost nalazi se u arhitekturi: nalozi kao nezavisni akteri, komunikacija porukama, determinističke adrese, cell-based podaci i mogućnost raspodele izvršavanja kroz shardove.

Ista arhitektura koja donosi skalabilnost zahteva od developera da ozbiljno razmišlja o parcijalnom uspehu, redosledu događaja i lokalnoj konzistentnosti.

TON zato nije težak zato što ima mnogo neobičnih termina. Težak je onda kada se pokušava programirati kao sistem koji nije.

Kada se contract posmatra kao state machine, poruka kao događaj, trace kao distribuirani workflow, a backend kao verifikator i projekcija blockchain stanja, TON postaje znatno razumljiviji.

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

Solana za developere: arhitektura bez EVM pretpostavki

Dora Milen — Fri, 18 Sep 2026 16:53:33 +0000

Ako Solani pristupite kao „bržem Ethereumu“, prve prototipe ćete verovatno napraviti brzo, ali ćete ubrzo početi da se borite protiv same platforme.

Solana nije EVM sa kraćim vremenom bloka. Njen programski model više podseća na operativni sistem u kojem se izvršni kod, podaci, dozvole i resursi eksplicitno navode pre izvršavanja. Program ne poseduje skriveni globalni storage. Klijent unapred opisuje koje naloge transakcija čita, koje menja i ko mora da je potpiše.

To je razlog zbog kog Solana može paralelno da obrađuje transakcije koje ne menjaju isto stanje. Istovremeno, to je izvor većine grešaka developera koji dolaze iz EVM sveta.

Ovaj članak objašnjava šta je Solana iz perspektive aplikacionog developera, kako rade nalozi i programi, gde se pojavljuje paralelizacija, kako izgleda realna integracija i koliko operacije zapravo koštaju. Fokus nije na maksimalnom teorijskom TPS-u, već na odlukama koje utiču na dizajn aplikacije.

Šta je Solana u praktičnom smislu

Za aplikacionog developera, Solana se može posmatrati kao distribuirano izvršno okruženje sa nekoliko osnovnih primitiva:

nalozi koji čuvaju SOL, podatke ili izvršni kod
programi koji obrađuju instrukcije
transakcije koje grupišu jednu ili više instrukcija
digitalni potpisi koji autorizuju promene
Program Derived Addresses, odnosno determinističke adrese bez privatnog ključa
Cross-Program Invocations za pozivanje drugih programa
JSON-RPC i WebSocket interfejsi za komunikaciju sa mrežom

Programi se kompajliraju u Solana Bytecode Format, odnosno sBPF, i izvršavaju se u sandbox okruženju. Programski kod je stateless u smislu da se promenljivo stanje ne čuva unutar izvršnog programa. Stanje se nalazi u odvojenim nalozima koji se prosleđuju instrukciji.[1]

Ovo razdvajanje je osnova cele arhitekture.

Na EVM-u je prirodno razmišljati ovako:

contract.state.balance[user]

Na Solani je bliži mentalni model:

program + instruction data + explicit account list

Program dobija naloge nad kojima treba da radi. Runtime proverava da li su označeni kao writable, da li su potrebni potpisnici prisutni i da li program ima pravo da menja njihove podatke.

Proof of History nije zamena za konsenzus

Proof of History često se opisuje kao Solanin konsenzusni mehanizam, ali je to pojednostavljenje koje nije naročito korisno developerima.

Proof of History je sekvencijalni kriptografski zapis koji mreži daje proverljiv redosled događaja i meru proteklog vremena. Konsenzus se i dalje oslanja na proof-of-stake glasanje validatora i Tower BFT pravila. Proof of History pomaže mreži da smanji deo komunikacije potreban za usaglašavanje oko vremena i redosleda događaja.[2]

Za većinu aplikacija nije potrebno implementaciono razumevanje Tower BFT-a. Važnije posledice su:

mreža je organizovana u slotove
validator koji je lider proizvodi blok za svoj slot
transakcija uključuje recent blockhash
blockhash ograničava životni vek transakcije
različiti nivoi potvrde predstavljaju različit nivo sigurnosti da stanje neće biti odbačeno

Drugim rečima, recent blockhash nije samo polje koje SDK zahteva. On je deo mehanizma za ograničavanje validnosti transakcije i zaštitu od ponovnog izvršavanja.

Nalog je osnovna jedinica stanja

Na Solani se praktično sve predstavlja nalogom. Svaki nalog ima istu osnovnu strukturu:

adresu od 32 bajta
balans izražen u lamportima
niz bajtova sa podacima
adresu programa koji je vlasnik naloga
executable zastavicu
istorijsko polje rent_epoch

Jedan SOL sadrži milijardu lamporta. Lamport je najmanja obračunska jedinica u kojoj RPC i programi predstavljaju SOL iznose.

Bitna razlika između vlasnika naloga i autoriteta korisnika često izaziva zabunu. Polje owner nije nužno wallet korisnika. Ono označava program koji sme da menja podatke naloga ili da umanjuje njegov SOL balans.

Na primer:

običan wallet nalog najčešće poseduje System Program
token nalog poseduje odgovarajući Token Program
nalog sa stanjem vaše aplikacije poseduje vaš program
executable nalog sadrži program koji runtime može da izvrši

Bilo koji program može dodati lamporte writable nalogu, ali samo program koji poseduje nalog može oduzeti lamporte ili menjati njegove podatke, uz dodatne runtime provere.[3]

Ovaj model ima praktičnu posledicu: aplikacija ne bi trebalo da „traži podatke unutar ugovora“. Ona treba da zna adresu naloga u kojem se podaci nalaze.

Nalozi nisu objekti u klasičnom smislu

Pretpostavimo da pravite marketplace i želite stanje porudžbine:

pub struct Order {
    pub buyer: Pubkey,
    pub seller: Pubkey,
    pub amount: u64,
    pub status: u8,
}

Na Solani ovaj objekat neće živeti u mapi unutar programa. Svaka porudžbina može biti poseban data account.

To donosi nekoliko prednosti:

porudžbine mogu da se čitaju direktno preko RPC-a
različite porudžbine mogu da se menjaju paralelno
nalog može imati determinističku adresu
trošak prostora može se pripisati korisniku koji kreira stanje
nalog se može zatvoriti, a njegov skladišni depozit vratiti

Ali postoje i troškovi:

morate projektovati adresiranje stanja
morate znati koliko bajtova alocirate
migracija strukture podataka zahteva planiranje
svaki nalog povećava listu naloga u transakciji
indeksiranje većeg broja naloga postaje zaseban infrastrukturni problem

Solana zato nagrađuje pažljivo modelovanje podataka. „Jedan veliki nalog za sve“ često stvara contention, dok „poseban nalog za svaki sitan događaj“ može nepotrebno povećati trošak skladišta i složenost indeksiranja.

Zašto eksplicitni nalozi omogućavaju paralelizaciju

Svaka instrukcija navodi:

program koji se poziva
listu naloga
da li je svaki nalog writable
da li nalog mora biti signer
niz bajtova sa argumentima instrukcije

Runtime iz liste naloga može da vidi koje transakcije imaju konflikt.

Ako transakcija A piše u nalog order_1, a transakcija B piše u order_2, nema nužnog konflikta. One mogu biti kandidati za paralelno izvršavanje.

Ako obe pišu u globalni nalog marketplace_state, moraju se serijalizovati oko tog writable naloga.

Važna nijansa je da se instrukcije unutar jedne transakcije izvršavaju redom. Paralelizacija se odnosi na raspoređivanje transakcija koje nemaju konfliktne write lockove. Sve instrukcije unutar jedne transakcije čine atomsku celinu: ili sve uspeju, ili se sve promene vraćaju.[4]

Zbog toga je izbor naloga istovremeno:

model podataka
sigurnosni model
concurrency model
deo troškovnog modela

Globalni brojač kao skriveni bottleneck

Čest prvi program izgleda ovako:

global_state.total_orders += 1

Ako svaka kupovina mora da menja isti global_state, sve kupovine konkurišu za isti writable nalog. Mreža može imati slobodne resurse, ali vaša aplikacija je sama uvela serijalizaciju.

Bolji dizajn može koristiti:

jedan PDA po porudžbini
particionisane agregate
periodično off-chain sabiranje
više shard naloga izabranih deterministički
događaje i indeksiranje umesto globalnog brojača

Ne postoji univerzalno rešenje. Bitno je da se writable account set tretira kao deo performansnog dizajna, a ne kao detalj SDK-a.

Program Derived Addresses kao zamena za internu mapu

Program Derived Address, odnosno PDA, deterministički se izvodi iz:

adrese programa
jednog ili više seed vrednosti
bump vrednosti

PDA se namerno nalazi van Ed25519 krive, pa za njega ne postoji privatni ključ. Samo program iz čijeg je ID-a PDA izveden može da „potpiše“ operaciju u njegovo ime, koristeći invoke_signed tokom Cross-Program Invocation poziva.[5]

Za marketplace porudžbinu adresa može konceptualno da se izvede iz:

["order", merchant_address, order_id]

Prednosti su praktične:

backend ne mora da čuva novu adresu u posebnoj tabeli
frontend može samostalno da izračuna adresu
program može proveriti da je prosleđen očekivani nalog
jedan skup seed vrednosti mapira se na jednu kanonsku adresu
PDA može biti autoritet token vault naloga

PDA nije nalog sam po sebi. Derivacija daje adresu, ali nalog na toj adresi i dalje mora biti kreiran i finansiran.

Seed vrednosti su deo javnog API-ja

Kada odaberete seed šemu, ona postaje deo protokola vaše aplikacije. Promena sa:

["order", order_id]

na:

["order", merchant, order_id]

menja sve izvedene adrese.

Zato seed šemu treba tretirati približno kao baznu šemu ili javni endpoint:

koristite stabilne prefikse
izbegavajte neograničene korisničke stringove
uključite tenant ili authority kada je potrebno
dokumentujte kodiranje numeričkih vrednosti
razmotrite verzionisanje seed šeme
koristite kanonski bump

Pojedinačni seed ima ograničenje od 32 bajta, a ukupan broj seed elemenata takođe je ograničen.[5]

Transakcija je atomski paket instrukcija

Solana transakcija sadrži:

jednu ili više instrukcija
listu adresa naloga
recent blockhash ili durable nonce
fee payer
potpise potrebnih signera

Legacy i v0 transakcije imaju maksimalnu veličinu od 1.232 bajta. Svaki Ed25519 potpis zauzima 64 bajta, a svaka puna adresa 32 bajta, pa limit može postati relevantan mnogo pre compute limita.[6]

V0 format podržava Address Lookup Tables. Umesto da svaku adresu stavite direktno u poruku, neke adrese se mogu referencirati indeksom iz on-chain tabele. To pomaže transakcijama koje komuniciraju sa većim brojem naloga i programa.

Aktuelna dokumentacija opisuje i v1 format sa većom porukom i drugačijim načinom definisanja resursnih limita. Ipak, format transakcije treba tretirati kao pregovaranu mogućnost između klijenta, walleta, RPC provajdera i validatora, a ne samo kao lokalni izbor biblioteke. RPC pozivi kao što su getTransaction i getBlock treba da navedu maxSupportedTransactionVersion koji aplikacija zaista ume da parsira.[7]

Atomskost je jedan od najkorisnijih primitiva

U jednu transakciju možete staviti više instrukcija, na primer:

kreiranje token naloga primaoca
transfer tokena
beleženje receipt naloga
promenu statusa porudžbine
emitovanje događaja iz programa

Ako treća instrukcija ne uspe, promene prethodnih instrukcija se vraćaju. Naknada za transakciju se ipak naplaćuje.

Ova atomskost omogućava settlement workflowe koji bi u klasičnom backendu zahtevali distribuiranu transakciju, outbox tabelu ili kompenzacione operacije. Ne uklanja potrebu za off-chain bazom, ali može ukloniti određene klase parcijalno završenih finansijskih operacija.

Realan use-case: kripto plaćanja i reconciliation

Dobar prvi Solana projekat nije DEX, lending protokol ili novi token. Realističniji use-case je servis koji prima kripto plaćanja i uparuje ih sa internim porudžbinama.

Takav sistem može da prihvata:

SOL
postojeći SPL token
stablecoin izdat preko originalnog Token Programa
token koji koristi Token Extensions Program

Za jednostavno plaćanje custom on-chain program često nije potreban. Standardni System Program i Token Program već implementiraju transfer.

Tipična arhitektura izgleda ovako:

flowchart LR
    A[Checkout API] --> B[Orders baza]
    A --> C[Wallet ili payment UI]
    C --> D[Potpisana Solana transakcija]
    D --> E[RPC node]
    E --> F[Solana cluster]
    F --> G[Indexer ili reconciliation worker]
    G --> B
    B --> H[Fulfillment servis]

Korak 1: Backend kreira nameru plaćanja

U SQL bazi kreira se porudžbina sa najmanje sledećim poljima:

order_id
expected_mint
expected_amount_base_units
recipient_address
reference
status
expires_at
transaction_signature

Iznos treba čuvati u osnovnim celobrojnim jedinicama tokena. Nemojte koristiti float ili double za finansijske vrednosti.

Korak 2: Klijent konstruiše transfer

Klijent kreira instrukciju za System Program ili odgovarajući Token Program. Transakcija dobija fee payer, recent blockhash i potrebne potpise.

Solana dokumentacija trenutno preporučuje @solana/kit kao TypeScript SDK. Kit koristi kompozicioni model sa pluginovima za signer, RPC i slanje transakcija.[8]

Minimalan lokalni SOL transfer može izgledati ovako:

import {
  createClient,
  generateKeyPairSigner,
  lamports,
} from "@solana/kit";
import {
  rpcAirdrop,
  solanaRpc,
} from "@solana/kit-plugin-rpc";
import {
  airdropPayer,
  payer,
} from "@solana/kit-plugin-signer";
import { getTransferSolInstruction } from "@solana-program/system";

const sender = await generateKeyPairSigner();
const recipient = await generateKeyPairSigner();

const LAMPORTS_PER_SOL = 1_000_000_000n;

const client = createClient()
  .use(payer(sender))
  .use(
    solanaRpc({
      rpcUrl: "http://localhost:8899",
      rpcSubscriptionsUrl: "ws://localhost:8900",
    }),
  )
  .use(rpcAirdrop())
  .use(airdropPayer(lamports(LAMPORTS_PER_SOL)));

const transfer = getTransferSolInstruction({
  source: sender,
  destination: recipient.address,
  amount: lamports(10_000_000n),
});

const { context } = await client.sendTransaction([transfer]);

console.log(context.signature);

Primer koristi lokalni validator i testni airdrop. Generisani keypair u memoriji prikladan je za test, ali nije model za produkciono čuvanje ključeva.

Backend koji kontroliše sredstva ne bi trebalo da drži nekriptovane keypair fajlove unutar repozitorijuma, container image-a ili običnih environment promenljivih. Produkcioni signer treba izolovati pomoću KMS-a, HSM-a, custody servisa ili drugog kontrolisanog signing sloja.

RPC endpointu se šalje već potpisana transakcija. RPC provajderu nikada nije potreban privatni ključ korisnika.[9]

Korak 3: Ne verujte samo uspehu wallet interfejsa

Dobijena signature vrednost znači da imate identifikator transakcije. Ne znači automatski da je transakcija:

uključena u blok
uspešno izvršena
potvrđena na zahtevanom nivou
poslala očekivani token
poslala očekivani iznos
poslata očekivanom primaocu

sendTransaction prosleđuje transakciju mreži, ali uspešan RPC odgovor nije dokaz konačnog izvršenja. Reconciliation servis mora proveriti status i sadržaj transakcije.[10]

Za plaćanje treba proveriti najmanje:

da je err jednak null
da je dostignut potreban commitment
da instrukcija koristi očekivani program
da je mint adresa tačna
da su source i destination token nalozi očekivani
da je transferisan tačan broj osnovnih jedinica
da signature nije već korišćen za drugu porudžbinu
da transakcija nije nastala pre kreiranja ili posle isteka porudžbine

Najvažnije pravilo je da se ne veruje objektu koji frontend pošalje backendu. Backend treba da pročita transakciju sa mreže i sam verifikuje njen sadržaj.

Korak 4: Napravite idempotentan reconciliation

RPC timeout ne znači da transakcija nije stigla do mreže. Ako backend odmah napravi novu transakciju sa novim blockhashom, može se dogoditi da obe transakcije budu izvršene.

Dok je originalni blockhash validan, treba ponovo slati iste potpisane bajtove i pratiti istu signature vrednost. Kada blockhash istekne, proverite istoriju i poslovno stanje pre pravljenja nove transakcije.[9]

U bazi postavite jedinstvena ograničenja nad:

transaction_signature
order_id
reference

Worker može bezbedno da se pokreće više puta ako stanje menja upitom poput:

UPDATE orders
SET status = 'paid',
    transaction_signature = $1
WHERE order_id = $2
  AND status = 'pending';

On-chain finalnost ne daje automatski idempotentnost vašem HTTP API-ju. To je i dalje odgovornost aplikacije.

Kada je potreban sopstveni program

Custom program ima smisla kada postoje pravila koja moraju biti izvršena atomski i nezavisno od vašeg backenda.

Primeri uključuju:

escrow između kupca i prodavca
podelu jedne uplate na više primalaca
uslovno oslobađanje sredstava
on-chain autorizaciju refundiranja
vault kontrolisan PDA autoritetom
isporuku digitalnog asseta zajedno sa uplatom
settlement između više tokena
transparentna pravila koja ne bi trebalo da zavise od jednog servera

Ako backend samo proverava da li je stablecoin stigao na adresu trgovca, custom program može biti nepotreban rizik. Standardni token transfer je jednostavniji, jeftiniji za održavanje i ima manje prostora za sigurnosne greške.

Ako plaćanje i promena stanja moraju biti jedna atomska operacija, program postaje opravdan.

Kratak Anchor primer: uplata i on-chain receipt

Anchor je framework za pisanje Solana programa u Rustu. On generiše deo boilerplate koda za deserijalizaciju instrukcija, validaciju naloga, diskriminatore i IDL.[11]

Sledeći primer prenosi SOL preko System Programa i kreira jedan receipt PDA po porudžbini:

use anchor_lang::prelude::*;
use anchor_lang::system_program;

declare_id!("11111111111111111111111111111111");

#[program]
pub mod checkout {
    use super::*;

    pub fn pay(
        ctx: Context<Pay>,
        order_id: [u8; 32],
        amount: u64,
    ) -> Result<()> {
        require!(amount > 0, CheckoutError::InvalidAmount);

        let transfer_accounts = system_program::Transfer {
            from: ctx.accounts.payer.to_account_info(),
            to: ctx.accounts.merchant.to_account_info(),
        };

        let transfer_context = CpiContext::new(
            ctx.accounts.system_program.to_account_info(),
            transfer_accounts,
        );

        system_program::transfer(transfer_context, amount)?;

        let receipt = &mut ctx.accounts.receipt;
        receipt.order_id = order_id;
        receipt.payer = ctx.accounts.payer.key();
        receipt.merchant = ctx.accounts.merchant.key();
        receipt.amount = amount;
        receipt.created_at = Clock::get()?.unix_timestamp;
        receipt.bump = ctx.bumps.receipt;

        Ok(())
    }
}

#[derive(Accounts)]
#[instruction(order_id: [u8; 32])]
pub struct Pay<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,

    #[account(mut)]
    pub merchant: SystemAccount<'info>,

    #[account(
        init,
        payer = payer,
        space = 8 + PaymentReceipt::INIT_SPACE,
        seeds = [
            b"receipt",
            merchant.key().as_ref(),
            order_id.as_ref(),
        ],
        bump,
    )]
    pub receipt: Account<'info, PaymentReceipt>,

    pub system_program: Program<'info, System>,
}

#[account]
#[derive(InitSpace)]
pub struct PaymentReceipt {
    pub order_id: [u8; 32],
    pub payer: Pubkey,
    pub merchant: Pubkey,
    pub amount: u64,
    pub created_at: i64,
    pub bump: u8,
}

#[error_code]
pub enum CheckoutError {
    #[msg("Iznos mora biti veći od nule")]
    InvalidAmount,
}

Transfer i kreiranje receipt naloga nalaze se u istoj transakciji. Ako transfer ne uspe, receipt se ne kreira. Ako kreiranje ili serijalizacija receipt naloga ne uspe, transfer se vraća.

PaymentReceipt::INIT_SPACE izračunava potreban prostor za polja, dok dodatnih osam bajtova pokriva Anchor diskriminator naloga.[12]

Primer ipak nije kompletan produkcioni checkout. Klijent trenutno može proslediti bilo koji merchant nalog. U produkciji bi merchant trebalo povezati sa verifikovanim configuration nalogom, na primer pomoću:

address ograničenja
has_one ograničenja
PDA konfiguracije trgovca
proverene marketplace authority vrednosti

Program mora proveravati poslovna pravila, a ne samo tipove podataka.

Anchor ograničenja nisu dekoracija

Kod Anchor programa, najveći deo sigurnosnog modela često se nalazi u #[derive(Accounts)] strukturi, a ne u handler funkciji.

Relevantna ograničenja uključuju:

Signer<'info> za obavezan potpis
#[account(mut)] za naloge koji se menjaju
seeds i bump za PDA validaciju
has_one za relacije između naloga
owner za proveru vlasničkog programa
address za očekivanu fiksnu adresu
close za zatvaranje naloga
realloc za promenu alociranog prostora
token i associated-token ograničenja

Nemojte koristiti UncheckedAccount samo da biste „naterali kod da se kompajlira“. Time odgovornost za sve validacije prelazi na handler, a jedna propuštena owner ili address provera može otvoriti ozbiljnu ranjivost.

Aktuelni Anchor takođe podrazumevano sprečava određene duplikate mutable naloga. Ako dva parametra smeju da budu ista adresa, to treba dozvoliti eksplicitno i obrazložiti.[13]

Cross-Program Invocation i kompozabilnost

Cross-Program Invocation, odnosno CPI, omogućava jednom programu da pozove instrukciju drugog programa.

Marketplace program može, na primer, pozvati:

System Program radi SOL transfera
Token Program radi token transfera
Associated Token Account Program radi kreiranja token naloga
drugi poslovni program radi isporuke asseta

Postoje dva osnovna mehanizma:

invoke kada su potrebni potpisi već prisutni u originalnoj transakciji
invoke_signed kada vaš program potpisuje u ime PDA adrese

Callee program ne može povećati privilegije koje nije dobio od caller programa. Nalog koji je read-only u parent instrukciji ne može postati writable u CPI pozivu. Isto važi za signer privilegije, osim validnog PDA potpisivanja kroz runtime.[14]

CPI troši compute budget iste transakcije. Duboki lanci poziva povećavaju compute potrošnju, otežavaju debugging i približavaju program limitima instruction stacka.

Kompozabilnost zato nije besplatna apstrakcija. Svaki dodatni program uvodi:

dodatne naloge u poruci
dodatnu compute potrošnju
potencijalni write contention
još jednu verzionisanu zavisnost
još jednu površinu za greške

SPL Token i Token Extensions nisu isto

Originalni Token Program pokriva standardne operacije:

kreiranje mint naloga
kreiranje token naloga
mintovanje
transfer
burn
delegate autorizaciju
freeze i thaw
promenu authority adresa
zatvaranje token naloga

Token Extensions Program, često nazivan Token-2022, podržava dodatne funkcije kroz ekstenzije, kao što su transfer fees, transfer hooks, metadata pointer, permanent delegate, non-transferable tokeni, confidential transfer mogućnosti i druge kontrole.[15]

Ključna projektantska odluka je da se većina mint ekstenzija bira prilikom kreiranja tokena. Ne mogu se sve naknadno dodati. Neke ekstenzije su međusobno nekompatibilne.

To znači da izdavanje tokena nije samo poziv createMint. Pre izdavanja treba analizirati:

koje wallet aplikacije podržavaju izabrane ekstenzije
koje berze i custody sistemi umeju da ih obrade
da li transfer hook može blokirati integracije
ko kontroliše privileged authorities
može li se authority opozvati
šta se događa ako custom hook program ne radi
koliko dodatnog prostora zahtevaju mint i token nalozi

Za aplikaciju koja samo prihvata postojeći stablecoin, sigurnije je integrisati njegov postojeći mint i program nego izdavati novi token bez jasne potrebe.

Koliko Solana integracija košta

Trošak nije jedna brojka. Sastoji se od najmanje četiri kategorije:

transakcione naknade
optional priority fees
skladišni depoziti za naloge
RPC i indekserska infrastruktura

Osnovna naknada

Aktuelna osnovna naknada iznosi 5.000 lamporta po potpisu. Transakcija sa više signera plaća osnovnu naknadu za svaki potpis.

Naknada se plaća i kada izvršavanje transakcije ne uspe.[16]

Zato retry logika koja stalno šalje nove, unapred osuđene transakcije nije samo tehnički problem. Ona nepotrebno troši sredstva fee payer naloga.

Priority fee

Za legacy i v0 transakcije, priority fee se zasniva na:

compute unit price × requested compute unit limit

Cena se izražava u micro-lamportima po compute unit jedinici, a konačan rezultat konvertuje u lamporte.

Važna posledica je da se naknada računa prema traženom compute limitu, ne prema stvarnoj potrošnji. Ako zatražite mnogo više compute units nego što transakcija koristi, plaćate prioritet i za neiskorišćeni deo limita.[16]

Praktičan workflow je:

konstruišite transakciju
simulirajte je
očitajte unitsConsumed
dodajte razumnu sigurnosnu marginu
postavite compute unit limit
izaberite priority fee prema trenutnim uslovima

Dokumentacija kao polaznu tačku navodi marginu od oko 10 procenata iznad simulirane potrošnje, ali produkcioni sistem treba da meri sopstvene transakcije i greške.[17]

Compute limiti

Za legacy i v0 format, podrazumevani limit za non-builtin instrukciju je 200.000 compute units, dok transakcija može zahtevati najviše 1.400.000 compute units.

Compute Units nisu isto što i vreme procesora u milisekundama. Oni su deterministička runtime mera operacija kao što su:

instrukcije virtuelne mašine
memorijske operacije
kriptografske funkcije
logging
CPI pozivi
serijalizacija podataka

Optimizacija programa zato uključuje smanjenje compute potrošnje, ali i izbor manjeg broja naloga, izbegavanje nepotrebnih CPI poziva i ograničavanje količine podataka koja se učitava.

Skladišni depozit

Nalog koji čuva podatke mora imati minimalan broj lamporta proporcionalan veličini naloga. Ovaj iznos nije klasična periodična hosting pretplata. Predstavlja minimalni balance koji ostaje zaključan dok nalog postoji.

Kada se nalog pravilno zatvori, lamporti se mogu vratiti na odabrani destination nalog.

Nemojte hardkodovati približan rent-exempt iznos iz bloga ili starog primera. Pre kreiranja naloga pozovite RPC metodu:

getMinimumBalanceForRentExemption

Ulaz je veličina podataka u bajtovima, a rezultat je potreban broj lamporta.[18]

Ako aplikacija pravi nalog po svakoj porudžbini, treba definisati:

ko finansira kreiranje
kada se nalog zatvara
kome se depozit vraća
da li je podatak zaista potreban zauvek
da li bi događaj i off-chain indexer bili bolji izbor

RPC trošak

Javni Solana RPC endpointi korisni su za razvoj, ali nisu odgovarajuća produkciona garancija.

Komercijalni RPC provajderi naplaćuju prema različitim modelima:

broj zahteva
ponderisana cena RPC metode
response bytes
bandwidth ili egress
broj WebSocket konekcija
arhivska istorija
dedicated kapacitet
dodatni transaction delivery servis

Zbog promenljivih ponuda nema smisla navoditi jednu „cenu Solane po mesecu“. Potrebno je meriti konkretan workload, posebno getProgramAccounts, istorijske transakcije, block upite i WebSocket subscriptions.[9]

RPC je deo sistema, ne samo URL u konfiguraciji

U prototipu RPC često izgleda kao jedna konstanta:

const RPC_URL = process.env.SOLANA_RPC_URL;

U produkciji RPC sloj utiče na:

svežinu podataka
uspešnost slanja transakcija
potvrđivanje
dostupnost istorije
latenciju korisničkog interfejsa
reconnect ponašanje WebSocket klijenta
tačnost reconciliation workera

Pouzdan setup treba da ima:

request timeout
ograničene retry pokušaje
exponential backoff sa jitterom
proveru slot freshness vrednosti
najmanje jedan nezavisni fallback za kritične putanje
odvojene metrike za read i write zahteve
HTTP reconciliation nakon WebSocket reconnecta

WebSocket obaveštenje nije durable message queue. Ako veza pukne, događaji mogu biti propušteni. Nakon reconnecta treba ponovo pročitati trenutno stanje preko HTTP RPC-a.[9]

Nemojte nasumično mešati RPC endpointove

Jedan endpoint može vratiti blockhash iz novijeg slota, dok drugi kasni i ne prepoznaje taj blockhash tokom simulacije ili slanja.

Operacije koje pripadaju istom transaction lifecycle-u poželjno je držati na jednom zdravom endpointu:

getLatestBlockhash
simulateTransaction
sendTransaction
getSignatureStatuses

Fallback treba uključiti kada postoje jasni signali da je endpoint spor, nedostupan ili zastareo, a ne round-robin rotacijom svakog poziva.

Commitment nivoi i korisničko iskustvo

Solana RPC koristi tri uobičajena commitment nivoa:

processed
confirmed
finalized

processed znači da je određeni čvor obradio blok, ali blok još može pripadati fork-u koji neće opstati.

confirmed znači da je blok dobio glasove supervećine stake-a.

finalized predstavlja dublje potvrđeno stanje koje je ukorenjeno u ledgeru.

Za većinu interaktivnih aplikacija confirmed daje praktičan balans između latencije i sigurnosti. Finansijski workflow može prikazati korisniku međustanje, ali fulfillment ili povlačenje sredstava odložiti do strožeg nivoa koji odgovara poslovnom riziku.[19]

Bitno je da frontend ne koristi termine kao što su „završeno“ i „potvrđeno“ bez jasno definisane semantike.

Dobar statusni model može biti:

created
awaiting_signature
submitted
processed
confirmed
finalized
failed
expired

Simulacija je deo normalnog workflowa

simulateTransaction izvršava transakciju nad stanjem dostupnim RPC čvoru, ali je ne šalje mreži.

Rezultat simulacije može sadržati:

runtime grešku
program logs
inner instructions
potrošene compute units
povratne podatke
pre i post balanse
učitane adrese

Simulacija je korisna za:

hvatanje grešaka pre wallet potpisa
procenu compute limita
prikaz razumljivije poruke korisniku
proveru da li su nalozi pravilno prosleđeni
debugging CPI lanca

Ali simulacija nije garancija izvršenja. Stanje se može promeniti između simulacije i slanja, blockhash može isteći, writable nalog može postati zauzet, a transakcija može izgubiti prioritet.[20]

Testiranje bez čekanja na Devnet

Devnet je koristan za integraciono testiranje, ali nije dobar inner development loop.

Anchor dokumentacija podržava više testnih pristupa:

LiteSVM za in-process Solana VM
Mollusk za fokusirano testiranje instrukcija
lokalni validator za RPC i validator ponašanje
Devnet za testiranje spoljne integracije
fuzzing za sistematsko traženje rubnih slučajeva

LiteSVM je prikladan za brzo testiranje programa i client koda. Lokalni validator je i dalje koristan kada su potrebne RPC metode ili ponašanje bliže pravom validatoru.[21]

Praktična test piramida može izgledati ovako:

Rust unit testovi za čistu poslovnu logiku
LiteSVM ili Mollusk testovi za instrukcije
lokalni validator za RPC workflow
mali broj Devnet end-to-end testova
Mainnet smoke test sa strogo ograničenim iznosima

Testirajte negativne putanje

On-chain test suite ne bi trebalo da potvrđuje samo happy path.

Obavezni slučajevi uključuju:

pogrešan signer
pogrešan owner naloga
pogrešan PDA
pogrešan bump
isti mutable nalog prosleđen na dva mesta
neautorizovan merchant
duplirana porudžbina
pogrešan mint
nedovoljan balance
prekoračen compute limit
overflow i underflow
zatvoren ili pogrešno inicijalizovan nalog
zamena legitimnog programa lažnim executable nalogom

Na Solani napadač kontroliše transakciju i izbor naloga koje šalje vašem programu. Program mora pretpostaviti da je svaki nalog neprijateljski dok sve relevantne osobine nisu proverene.

Trade-off: brzina mreže ne uklanja složenost aplikacije

Solana može biti veoma dobar izbor za aplikacije koje imaju:

veliki broj nezavisnih promena stanja
interaktivna plaćanja
on-chain tržišta
igre sa čestim korisničkim akcijama
programe koji komponuju više protokola
tokene sa specifičnim pravilima
potrebu za atomskim settlementom

Međutim, nije besplatna zamena za bazu podataka.

Prednosti

eksplicitno stanje omogućava paralelno izvršavanje
više instrukcija može se izvršiti atomski
PDA uklanja upravljanje privatnim ključevima za programske autoritete
standardni programi pružaju zajedničke primitive
naknade su deterministički izražene u lamportima
nalog je direktno adresabilna jedinica podataka
Rust i Anchor daju relativno strogo razvojno okruženje

Nedostaci

account model zahteva drugačiji način razmišljanja
transaction size može biti ograničenje
writable account contention može poništiti paralelizaciju
RPC infrastruktura postaje kritična komponenta
on-chain skladištenje traži depozit
programi imaju stroge compute i memorijske limite
parsing transakcija i token operacija nije trivijalan
wallet, RPC i transaction-version kompatibilnost moraju se pratiti
upgrade authority uvodi operativni i governance rizik

Upgrade authority je deo threat modela

Program postavljen preko upgradeable loadera može imati upgrade authority. Ko kontroliše taj ključ, može postaviti novu verziju programa.

Zato „program je na blockchainu“ ne znači automatski da je nepromenljiv.

Produkcioni tim mora odlučiti:

da li program treba da ostane upgradeable
da li authority pripada jednom ključu ili multisig sistemu
postoji li timelock ili javni proces promene
kako se verifikuje novi build
kako se korisnici obaveštavaju o upgrade-u
kada authority treba trajno opozvati

Opozivanje upgrade authority vrednosti program čini immutable, ali tada se greške više ne mogu ispraviti redeployem na istoj adresi. To je sigurnosni trade-off, ne checkbox za decentralizaciju.[1]

Razuman razvojni workflow

Za prvi ozbiljan Solana projekat workflow može izgledati ovako.

1. Prvo modelujte naloge

Pre pisanja programa odgovorite:

koji podatak mora biti on-chain
koji program poseduje svaki nalog
ko finansira njegovo kreiranje
ko sme da ga menja
kako se izvodi njegova adresa
može li se zatvoriti
koji workflowi pišu u isti nalog

2. Prototipujte bez custom programa

Ako use-case može da koristi System Program ili Token Program, prvo napravite tu verziju.

To pomaže da odvojeno rešite:

wallet povezivanje
transakcije
RPC
potvrđivanje
reconciliation
finansijsku preciznost
monitoring

3. Uvedite program samo za atomsku logiku

Program treba da rešava pravilo koje nije bezbedno ostaviti backendu, kao što su escrow, split ili programski vault.

4. Simulirajte svaku klasu transakcije

Sakupljajte:

compute units
veličinu poruke
broj naloga
broj signera
učestalost neuspeha
tip runtime greške

5. Testirajte konfliktno opterećenje

Ne merite samo koliko jedna transakcija traje. Pošaljite konkurentne transakcije koje:

menjaju različite PDA naloge
menjaju isti globalni nalog
koriste isti vault
pozivaju isti program sa različitim writable setovima

Tako ćete otkriti da li vaš model stanja omogućava paralelizaciju koju očekujete.

6. Projektujte retry i idempotency pre Mainneta

Za svaku write operaciju definišite:

stabilan application-level identifikator
mapiranje na signature
ponašanje pre blockhash isteka
ponašanje posle isteka
proveru da li je operacija već izvršena
maksimalan broj retry pokušaja

7. Odvojite chain state od projection baze

Blockchain je izvor istine za on-chain stanje, ali nije nužno najbolji query engine za proizvod.

Produkcione aplikacije često održavaju SQL ili analitičku projekciju za:

pretragu
filtriranje
agregate
istoriju korisnika
notifikacije
dashboarde
poslovne izveštaje

Indexer mora biti sposoban za replay i reconciliation. Ako WebSocket worker propusti događaj, stanje mora moći da se obnovi iz RPC istorije ili drugog pouzdanog izvora.

Kada Solana verovatno nije pravi izbor

Solana možda nije opravdana ako:

svi korisnici veruju jednom backendu
nema potrebe za digitalnim vlasništvom ili settlementom
podaci moraju ostati privatni
promene stanja su retke i jednostavne
aplikacija nema način da bezbedno upravlja ključevima
tim ne može da održava RPC, indeksiranje i monitoring
zahtev se može rešiti običnim payment processorom i SQL bazom

Blockchain uvodi distribuiranu verifikaciju i mogućnost kompozicije, ali takođe uvodi ključeve, naknade, javno stanje, nepromenljivu istoriju i drugačiji operativni model.

Dobra Solana aplikacija ne stavlja sve on-chain. Ona bira najmanju količinu stanja koja mora biti javno proverljiva ili atomski menjana.

Zaključak

Solanina najvažnija osobina za developera nije reklamirani TPS. To je eksplicitni account model.

Kada transakcija unapred navodi naloge koje čita i menja, runtime dobija dovoljno informacija da raspoređuje nezavisne transakcije paralelno. Cena tog dizajna je da developer mora da projektuje stanje, adrese, write lockove i authority relacije mnogo pažljivije nego u sistemu sa implicitnim globalnim storageom.

Najpraktičniji početak nije pisanje velikog DeFi protokola. Bolje je napraviti mali payment ili escrow workflow i proći ceo životni ciklus:

konstruisanje instrukcije
određivanje naloga
simulacija
potpisivanje
slanje
potvrđivanje
on-chain verifikacija
idempotentno knjiženje
oporavak od RPC greške

Tek tada account model prestaje da deluje neobično i počinje da pokazuje zašto je koristan.

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

Litecoin za developere: pouzdana infrastruktura plaćanja

Dora Milen — Fri, 18 Sep 2026 16:30:48 +0000

Litecoin je decentralizovana mreža za prenos digitalne vrednosti, nastala iz Bitcoinovog koda, ali sa kraćim ciljanim intervalom između blokova, Scrypt proof-of-work algoritmom i maksimalnom ponudom od 84 miliona LTC. Prosečan ciljani interval bloka je približno dva i po minuta, dok se nagrada rudarima prepolovljava na svakih 840.000 blokova.

To su osnove koje većina developera već zna. Zanimljivije pitanje je zašto bi neko danas integrisao Litecoin kada postoje Bitcoin, Lightning, stablecoini, Ethereum L2 mreže i brojni payment provideri.

Odgovor nije da je Litecoin objektivno najbolji blockchain. Nije. Njegova vrednost je u užem skupu karakteristika: jednostavan UTXO model, relativno predvidivo procesiranje transakcija, niske mrežne naknade, široka podrška novčanika i menjačnica, opcioni MWEB sloj i infrastruktura veoma slična Bitcoin Core ekosistemu.

Za developera koji želi da prihvata kripto plaćanja bez pokretanja smart contract platforme, Litecoin je i dalje razumna, prilično konzervativna opcija.

Šta Litecoin zapravo nudi aplikaciji

Litecoin nije baza podataka sa proizvoljnim poslovnim pravilima. Nema smisla koristiti ga za skladištenje korisničkih profila, složene tokene, on-chain aukcije ili opštu programabilnost kakvu nude Ethereum i slične platforme.

Njegova primarna funkcija je mnogo uža:

korisnik kontroliše izlaze transakcija privatnim ključevima
transakcije troše postojeće UTXO izlaze
rudari ih uključuju u blokove
mreža prihvata lanac sa najvećom akumuliranom količinom rada
aplikacija prati transakciju i procenjuje kada je dovoljno potvrđena

Ta ograničenost je istovremeno i prednost. Manje pokretnih delova znači manju površinu za greške. Kod klasičnog Litecoin plaćanja nema dozvola tokena, proxy ugovora, upgrade ključeva, issuer blockliste niti zavisnosti od stanja nekog DeFi protokola.

Ako kupac pošalje LTC na validnu adresu, glavna pitanja za backend su:

Da li je transakcija viđena?
Da li plaća očekivani iznos?
Da li je uključena u blok?
Koliko potvrda ima?
Da li je došlo do reorganizacije lanca?
Da li su sredstva bezbedno prebačena iz operativnog novčanika?

To je dovoljno mali problem da ga tim može razumeti od početka do kraja.

Zašto je Litecoin i dalje relevantan

Predvidiv i poznat tehnički model

Litecoin Core je izveden iz Bitcoin Core koda, pa su arhitektura čvora, RPC model, wallet koncepti, UTXO skup, mempool i način obrade blokova poznati svakome ko je ranije radio sa Bitcoin infrastrukturom.

To smanjuje cenu učenja. Znanje o sledećim konceptima uglavnom je prenosivo:

raw transakcije
ulazi i izlazi
change adrese
fee rate
potvrde i reorganizacije
watch-only novčanici
descriptor modeli
JSON-RPC
ZeroMQ obaveštenja
cold i hot wallet razdvajanje

Ipak, prenosivost ne znači binarnu kompatibilnost. Litecoin ima sopstvene mrežne parametre, prefikse adresa, genesis blok, portove, proof-of-work algoritam i dodatnu MWEB logiku. Bitcoin biblioteka ne sme automatski biti proglašena Litecoin bibliotekom samo zato što obe obrađuju slične transakcije.

Kraći interval između blokova

Ciljani interval od približno dva i po minuta često čini potvrđivanje praktičnijim za klasične online kupovine nego čekanje Bitcoin bloka. To ne znači da će svaki Litecoin blok stići za tačno dva i po minuta. Rudarenje je probabilistički proces, pa pojedinačni interval može biti mnogo kraći ili duži.

Takođe, četiri Litecoin potvrde nisu matematički univerzalni ekvivalent jednoj Bitcoin potvrdi. Bezbednost zavisi od ekonomije rudarenja, hash rate distribucije, vrednosti transakcije, mogućnosti napadača i politike primaoca. Vreme bloka je samo jedan parametar.

Za digitalni proizvod male vrednosti možda je prihvatljivo reagovati već na mempool transakciju, uz jasno razumevanje rizika. Za isplatu robe visoke vrednosti može biti potrebno više potvrda i dodatna provera transakcije.

Naknade pogodne za jednostavna plaćanja

Litecoin naknada nije procenat poslatog iznosa. Ona prvenstveno zavisi od veličine transakcije i trenutnog fee rate-a. Transakcija sa mnogo ulaza može biti skuplja od transakcije sa jednim ulazom, čak i kada šalje manji iznos.

U normalnim uslovima mrežne naknade često omogućavaju male transfere koji ne bi bili praktični na skupljem osnovnom sloju. Ipak, aplikacija ne treba da hardkoduje pretpostavku da je Litecoin transfer uvek jeftin. Fee treba proceniti neposredno pre kreiranja transakcije, pomoću sopstvenog čvora ili proverene infrastrukture.

Ukupan trošak integracije obuhvata više od blockchain naknade:

server i skladište za čvor
monitoring i backup
razvoj i održavanje payment servisa
bezbedno upravljanje ključevima
kursnu razliku pri konverziji
naknadu provajdera ili berze
računovodstvo i regulatorne obaveze
trošak pogrešnih, duplih ili ručno obrađenih uplata

Sama mreža može biti jeftina, a operativni sistem oko nje skup.

Proof-of-work bez nove bezbednosne paradigme

Litecoin koristi Scrypt proof-of-work. Dugo postojanje mreže i specijalizovana rudarska infrastruktura daju mu zreliji bezbednosni profil od malih proof-of-work lanaca.

Važan deo ekonomije rudarenja je merged mining sa Dogecoin mrežom. Rudari mogu koristiti isti Scrypt rad za zaštitu obe mreže, što menja ekonomsku računicu i omogućava deljenje rudarske infrastrukture.

Ipak, Litecoin nema istu ekonomsku težinu ni ukupnu rudarsku dominaciju kao Bitcoin. Za veoma velike transfere to treba tretirati kao realan trade-off, a ne kao detalj koji rešava veći broj potvrda.

MWEB je najzanimljiviji deo Litecoina

MimbleWimble Extension Blocks, odnosno MWEB, uveden je kao opcioni prošireni deo Litecoin protokola. Extension block se vezuje za osnovni lanac, dok se sredstva mogu premestiti u njega i vratiti iz njega putem peg-in i peg-out procesa.

Cilj MWEB-a je bolja zamenljivost novca i manja količina javno vidljivih finansijskih podataka. U MWEB delu transakcije iznosi nisu javno izloženi kao kod standardnih UTXO izlaza, dok MimbleWimble konstrukcije, agregacija i cut-through smanjuju direktnu vezu između pojedinačnih ulaza i izlaza.

To nije isto što i tvrdnja da je korisnik potpuno anoniman.

Posmatrač i dalje može koristiti:

mrežne metapodatke
tajming transakcija
informacije sa menjačnica
KYC evidenciju
obrasce ulaska u MWEB i izlaska iz njega
podatke kompromitovanog novčanika
ponašanje korisnika na drugim servisima

MWEB zato treba opisivati kao alat za poverljivost i zamenljivost, ne kao garanciju anonimnosti.

Zašto je MWEB relevantan developerima

Na potpuno javnom blockchainu trgovac može videti više podataka nego što mu je potrebno. Plaćanje otkriva ulaze transakcije, iznose i potencijalne veze sa drugim adresama. Isto važi i u suprotnom smeru: kupac može analizirati adresu trgovca i povezane tokove.

Za poslovnu aplikaciju to može biti problem privatnosti. Javni promet dobavljača, stanje operativnog novčanika ili obrasci isplate zaposlenima ne treba nužno da budu dostupni konkurenciji.

MWEB nudi zanimljiv kompromis: osnovni Litecoin ostaje kompatibilan sa klasičnim UTXO alatima, dok korisnici koji žele veću poverljivost mogu koristiti opcioni sloj.

Cena tog kompromisa je integraciona fragmentacija. Ne podržavaju svi novčanici, procesori plaćanja, berze i blockchain exploreri MWEB. Neke platforme mogu podržavati LTC, ali ne i MWEB depozite ili isplate. Sistem zato mora eksplicitno razlikovati standardni Litecoin transfer od MWEB toka.

Ne treba prikazati MWEB adresu korisniku dok nije provereno da njegov novčanik i odabrani izlazni servis zaista podržavaju takav transfer.

Realan use-case: naplata digitalne usluge

Zamislimo SaaS proizvod koji prodaje jednokratne kredite, API pakete ili pristup datoteci. Korisnik ne mora da otvara nalog kod kartičnog procesora niti da deli podatke kartice sa trgovcem. Aplikacija želi da prihvati LTC, ali ne želi da prepusti kompletan payment state trećoj strani.

Minimalna arhitektura izgleda ovako:

flowchart LR
    A[Korisnik] -->|Šalje LTC| B[Jedinstvena adresa fakture]
    B --> C[Litecoin mreža]
    C --> D[Litecoin Core čvor]
    D -->|RPC ili ZMQ| E[Payment watcher]
    E --> F[(Baza faktura)]
    E --> G[Order servis]
    G --> H[Digitalni proizvod]
    E --> I[Wallet sweep proces]
    I --> J[Cold wallet]

Najvažniji deo nije generisanje adrese. Najvažniji deo je model stanja fakture.

Razuman skup stanja može biti:

created
awaiting_payment
seen_in_mempool
underpaid
paid_unconfirmed
paid_confirmed
expired
overpaid
refunded
reorged
manual_review

Nazivi nisu protokolski standard. Oni pripadaju aplikaciji. Poenta je da uplata nije jedan boolean.

Kreiranje fakture

Korisnik bira Litecoin kao način plaćanja. Backend zatim:

Uzima aktuelnu LTC cenu od izabranog izvora.
Izračunava iznos koristeći definisana pravila zaokruživanja.
Kreira kratkotrajnu ponudu sa vremenom isteka.
Generiše novu adresu samo za tu fakturu.
Čuva adresu, očekivani iznos, kurs, rok i mrežu.
Vraća korisniku adresu i iznos.

Jedinstvena adresa po fakturi pojednostavljuje povezivanje transakcije sa narudžbinom i smanjuje nepotrebno povezivanje korisnika. Ponovna upotreba adresa otežava računovodstvo i pogoršava privatnost.

Ako wallet pod nazivom merchant postoji i učitan je, Litecoin Core CLI može generisati novu bech32 adresu:

litecoin-cli -rpcwallet=merchant \
    getnewaddress "invoice:8f2c1a" "bech32"

Labela je pomoćni podatak novčanika, ne deo blockchain konsenzusa. Interni ID ne treba da sadrži e-mail, ime kupca ili drugi lični podatak.

Za proveru stanja čvora može se koristiti:

litecoin-cli getblockchaininfo

Produkcioni servis ne bi trebalo da izvršava CLI proces za svaki zahtev. Uobičajeno je da komunicira sa lokalnim JSON-RPC interfejsom, uz autentifikaciju, ograničene mrežne dozvole i izolovan servisni nalog.

RPC port nikada ne treba javno izložiti internetu. Reverse proxy bez pravilno projektovane autentifikacije nije dovoljna zaštita za interfejs koji može upravljati novčanikom.

Detekcija transakcije

Postoje tri osnovna pristupa:

periodično RPC skeniranje
obrada novih blokova i mempoola
ZeroMQ obaveštenja uz naknadnu RPC verifikaciju

Polling je najjednostavniji, ali povećava latenciju i broj RPC poziva. ZMQ je efikasniji za događaje, ali obaveštenje nije trajni message queue. Ako servis nije bio povezan, događaj može biti propušten. Zato ZMQ ne sme biti jedini izvor istine.

Robustan obrazac je:

ZMQ signal javlja da postoji nova transakcija ili blok.
Worker učitava detalje preko RPC-a.
Rezultat upisuje idempotentno.
Periodični reconciliation posao skenira blokove od poslednje obrađene visine.
Sistem ponovo računa broj potvrda i proverava reorganizacije.

Baza treba da čuva najmanje:

txid
identitet izlaza, tipično txid i vout
adresu fakture
primljeni iznos u najmanjim jedinicama
visinu bloka, ako je potvrđena
hash bloka
trenutno poznat broj potvrda
vreme prvog opažanja
status obrade

Čuvanje samo txid nije uvek dovoljno. Jedna transakcija može imati više izlaza, uključujući više izlaza ka adresama koje kontroliše ista aplikacija.

Novac se ne obrađuje kao floating-point vrednost

Litecoin ima osam decimalnih mesta. Iznose unutar aplikacije treba čuvati kao celobrojni broj najmanjih jedinica, koristeći BIGINT, bigint ili odgovarajući decimalni tip baze.

Kratka TypeScript funkcija za konverziju decimalnog stringa može izgledati ovako:

function toAtomicUnits(value: string): bigint {
    if (!/^\d+(\.\d{1,8})?$/.test(value)) {
        throw new Error("Invalid LTC amount");
    }

    const [whole, fraction = ""] = value.split(".");
    const paddedFraction = fraction.padEnd(8, "0");

    return BigInt(whole) * 100_000_000n + BigInt(paddedFraction);
}

Važno je da ulaz bude string. Ako se vrednost prethodno pretvori u JavaScript number, preciznost je možda već izgubljena.

Isti princip važi za poređenje primljenog i očekivanog iznosa. Ne treba koristiti toleranciju tipa Math.abs(a - b) < epsilon za finansijsko stanje.

Potvrde nisu monotoni brojač

Aplikacije često pretpostave da potvrđena transakcija može samo dobijati nove potvrde. U praksi reorganizacija lanca može ukloniti blok iz aktivnog lanca.

Zato je korisno sačuvati i hash bloka u kojem je uplata pronađena. Kada stigne novi vrh lanca, payment servis proverava da li je taj blok i dalje deo aktivnog lanca. Ako nije, faktura privremeno prelazi u stanje reorged ili ponovo u paid_unconfirmed.

Poslovna odluka zavisi od proizvoda:

jeftin digitalni sadržaj može se isporučiti uz mali broj potvrda
fizička roba može čekati duže
velika isplata može zahtevati dodatnu ručnu proveru
nepovratna radnja ne treba da zavisi samo od mempool prisustva

Broj potvrda ne treba kopirati iz tuđe integracije. To je parametar rizika konkretne aplikacije.

Delimične i višestruke uplate

Korisnik može poslati manje od očekivanog iznosa, platiti iz dve transakcije ili izvršiti uplatu nakon isteka kursa.

Sistem mora unapred definisati politiku:

Da li sabira više UTXO izlaza na istoj adresi?
Koliko dugo čeka ostatak?
Ko snosi blockchain naknadu refundacije?
Da li se mala razlika prihvata?
Po kom kursu se obrađuje zakašnjela uplata?
Kako se tretira preplata?
Da li refundacija zahteva novu adresu korisnika?

Automatska refundacija na jednu od ulaznih adresa nije bezbedna pretpostavka. Ulaz može pripadati custodial servisu ili berzi, a ne krajnjem korisniku. Refund adresu treba prikupiti i validirati kroz eksplicitan proces.

Sopstveni čvor ili tuđi API

Najvažnija infrastrukturna odluka nije izbor SDK-a, već izbor izvora istine.

Sopstveni Litecoin Core čvor

Prednosti:

nezavisna validacija blokova i transakcija
nema curenja svih korisničkih adresa ka jednom API provajderu
potpuna kontrola RPC i wallet politike
jednostavnije praćenje reorganizacija
nema vendor-specific modela potvrda
pristup mempoolu i sirovim transakcijama

Nedostaci:

sinhronizacija zahteva vreme, disk i mrežni saobraćaj
čvor mora biti ažuriran i nadziran
wallet backup i enkripcija ostaju vaša odgovornost
RPC interfejs zahteva pažljivu mrežnu izolaciju
incidenti MWEB validacije ili konsenzusne izmene mogu zahtevati hitnu nadogradnju

Aktuelne Litecoin Core objave treba pratiti direktno u zvaničnom repozitorijumu. Najnovije izdanje u trenutku provere je v0.21.5.8, maintenance verzija sa izmenama vezanim za MWEB validaciju, relay, rudarenje i upravljanje resursima. Napomene uz izdanje posebno preporučuju nadogradnju rudarima, poolovima, berzama i MWEB operatorima.

Verziju ne treba hardkodovati u trajnu dokumentaciju za deployment. Pipeline bi trebalo da proverava potpis, checksum i zvanično izdanje koje tim eksplicitno odobri.

Hosted blockchain API

Prednosti:

brži početak razvoja
nema inicijalne sinhronizacije
manje sistemske administracije
često postoji indeksiranje adresa i webhook podrška

Nedostaci:

provider vidi koje adrese pratite
rezultat zavisi od njegovog čvora i indeksiranja
webhook može kasniti ili biti dupliran
limiti i cenovni model mogu se promeniti
podrška za MWEB može biti ograničena
aplikacija postaje zavisna od nestandardnog API-ja

Dobar kompromis za prototip je provider uz sopstvenu bazu i apstrakcioni sloj. Za ozbiljan payment sistem ima smisla dodati sopstveni čvor kao primarni ili nezavisni verifikacioni izvor.

Upravljanje ključevima je teži problem od RPC-a

Kod za pozivanje getnewaddress je trivijalan. Bezbedno čuvanje privatnih ključeva nije.

Payment arhitektura obično razdvaja tri uloge:

watcher prati adrese i transakcije, bez mogućnosti trošenja
hot wallet potpisuje ograničene operativne transfere
cold wallet čuva većinu sredstava van aplikacionog servera

Ako web aplikacija ima neograničen pristup wallet RPC-u, SQL injection ili remote code execution incident lako postaje finansijski incident.

Bolji model je:

Frontend nikada ne komunicira direktno sa čvorom.
Payment servis ima samo potrebne RPC dozvole.
Watch-only komponenta prati uplate.
Poseban signer odobrava isplate.
Automatski sweep ima dnevne i pojedinačne limite.
Veći transferi zahtevaju dodatno odobrenje.
Backup seed-a i descriptor podataka testira se restauracijom.

Enkripcija wallet fajla štiti podatke u mirovanju, ali ne štiti otključan proces koji je napadač već preuzeo. HSM ili eksterni signer može smanjiti rizik, ali uvodi novu složenost i mora zaista podržavati Litecoin parametre.

UTXO upravljanje se ne sme ostaviti za kasnije

Kada servis primi hiljade malih uplata, njegov saldo nije jedna brojka. To je skup velikog broja nepotrošenih izlaza.

Kasnija isplata može zahtevati mnogo ulaza, što povećava veličinu transakcije i naknadu. To može dovesti do:

skupog sweep-a
sporijeg konstruisanja transakcija
većeg curenja podataka kroz povezivanje ulaza
problema sa minimalnim ekonomskim iznosima
otežanog računovodstva

Servis treba da ima eksplicitnu coin selection i consolidation politiku. Konsolidacija je obično povoljnija kada je mempool miran, ali spajanje mnogo UTXO izlaza javno pokazuje da verovatno pripadaju istom entitetu.

MWEB može poboljšati privatnost određenih tokova, ali ne uklanja potrebu za operativnim planiranjem.

Litecoin naspram drugih opcija

Opcija	Gde je jaka	Gde je slabija
Litecoin	Jednostavna on-chain plaćanja, niske naknade, UTXO model, MWEB opcija	Manji ekosistem, volatilnost LTC-a, neujednačena MWEB podrška
Bitcoin osnovni sloj	Najveća ekonomska i rudarska bezbednost, zrela infrastruktura	Duži ciljani interval blokova i potencijalno skuplje male uplate
Lightning Network	Brza mikroplaćanja i mali marginalni trošak	Likvidnost kanala, routing, invoice lifecycle i složenije operacije
Stablecoini	Stabilnija obračunska vrednost i jednostavnije formiranje cena	Rizik izdavaoca, mrežni token za gas, više lanaca i moguća blokada sredstava
Ethereum i L2 mreže	Smart contract programabilnost i veliki aplikacioni ekosistem	Veća površina za greške, bridge rizici i složenija integracija
Privacy coin mreže	Privatnost ugrađena kao centralna karakteristika	Slabija podrška servisa i veći regulatorni i integracioni otpor

U odnosu na Bitcoin

Litecoin nudi kraće očekivano vreme do prvog bloka i često niže naknade, ali Bitcoin ima veću ekonomsku težinu, širu institucionalnu infrastrukturu i snažniji bezbednosni budžet.

Ako je prioritet maksimalna otpornost za veoma velike iznose, Bitcoin je obično prirodniji izbor. Ako je prioritet jednostavna on-chain naplata manjih iznosa, Litecoin može pružiti prijatniji korisnički tok.

U odnosu na Lightning

Lightning je bolji kandidat kada aplikacija zahteva gotovo trenutna, česta i veoma mala plaćanja. Međutim, Lightning integracija uvodi upravljanje kanalima, ulaznom i izlaznom likvidnošću, istekom faktura, routing neuspesima i rezervnim tokovima.

Litecoin on-chain integracija je sporija, ali konceptualno jednostavnija. Adresa može dugo primati uplate, a sredstva se mogu pratiti standardnim UTXO alatima.

U odnosu na stablecoine

Stablecoin je često bolji payment asset za trgovca koji ne želi volatilnost. Faktura od 20 EUR mnogo je lakša za računovodstvo ako primljena imovina pokušava da prati fiat vrednost.

Ali stablecoin uvodi druge zavisnosti:

centralnog izdavaoca
konkretan smart contract
mrežu na kojoj se token nalazi
gas token za slanje
rizik pogrešno izabrane mreže
mogućnost zamrzavanja adrese
bridge ili wrapped-asset rizik

Litecoin nema stabilnu cenu, ali nema ni token contract ni centralnog izdavaoca koji može promeniti pravila samog LTC sredstva.

U odnosu na smart contract platforme

Ako aplikacija zahteva escrow sa složenim uslovima, programabilne tokene ili kompozabilnost sa drugim protokolima, Litecoin nije prirodan izbor.

Njegov scripting sistem je namerno ograničeniji. To smanjuje mogućnosti, ali i broj načina na koje aplikacija može izgubiti sredstva zbog greške u ugovoru.

Ne treba birati smart contract platformu za problem koji zahteva samo: „Korisnik je uplatio tačan iznos na adresu.“

Najveće mane Litecoina

Volatilnost

LTC nije stabilna obračunska jedinica. Cena može značajno da se promeni između kreiranja fakture, potvrde transakcije i konverzije.

Aplikacija zato mora definisati:

izvor kursa
period važenja ponude
način zaokruživanja
politiku zakašnjelih uplata
trenutak konverzije
ko snosi rizik promene cene

Ovo nije detalj korisničkog interfejsa. To je deo finansijskog modela proizvoda.

Slabija programabilnost

Litecoin nije general-purpose izvršno okruženje. Developer dobija robustan transfer vrednosti, ali ne i bogat smart contract runtime.

Za mnoge payment sisteme to je prednost. Za protokole koji zahtevaju kompleksno stanje, oracle podatke ili on-chain governance predstavlja čvrsto ograničenje.

Fragmentacija oko MWEB-a

MWEB je tehnički zanimljiv, ali podrška nije univerzalna. Integracija koja pretpostavlja da svaki LTC wallet može poslati na svaki tip adrese verovatno će napraviti loše korisničko iskustvo.

Aplikacija mora jasno označiti:

koju vrstu adrese prikazuje
da li podržava standardni LTC, MWEB ili oba
da li servis sa kojeg korisnik šalje podržava tu opciju
kako izgleda fallback tok

Manji developerski ekosistem

Većina blockchain SDK-ova prvo cilja Bitcoin ili Ethereum. Litecoin podrška ponekad postoji samo kao konfiguraciona opcija, fork ili community dodatak.

To zahteva dodatnu proveru:

da li biblioteka pravilno validira Litecoin adrese
da li koristi odgovarajuće mrežne parametre
da li podržava SegWit i potrebne tipove skripti
da li je testirana na Litecoin testnetu
da li razume MWEB, ako je to potrebno
da li je aktivno održavana

Bolje je koristiti Litecoin Core kao izvor istine nego verovati biblioteci samo zato što u dokumentaciji ima litecoin: true.

Produkcioni checklist

Pre prihvatanja stvarnog novca, tim bi trebalo da proveri sledeće:

Svaka faktura dobija novu adresu.
Iznosi se čuvaju kao celobrojne najmanje jedinice.
RPC nije javno dostupan.
Kredencijali nisu u repozitorijumu.
Privatni ključevi nisu dostupni frontend ili opštem API procesu.
Webhook i ZMQ događaji obrađuju se idempotentno.
Postoji periodični reconciliation sa lancem.
Reorganizacije mogu vratiti status fakture unazad.
Postoje pravila za delimičnu, višestruku i zakašnjelu uplatu.
Refundacija ne ide automatski na proizvoljnu ulaznu adresu.
Potvrde zavise od vrednosti i rizika transakcije.
Wallet backup je testiran stvarnom restauracijom.
Čvor ima monitoring za visinu lanca, peerove, disk i verziju.
UTXO konsolidacija je planirana.
MWEB se nudi samo tamo gde je kompletan tok podržan.
Testnet testovi obuhvataju restart, duplikate i propuštene događaje.
Računovodstvo čuva kurs, vreme i identitet izvora cene.
Nadogradnje Litecoin Core-a prolaze kontrolisan deployment.

Kada Litecoin ima smisla

Litecoin je dobar kandidat kada aplikaciji treba:

jednostavan kripto payment rail
direktna on-chain naplata
relativno kratko čekanje do prvog bloka
niska tipična mrežna naknada
sopstvena validacija bez zavisnosti od hosted API-ja
UTXO infrastruktura slična Bitcoinovoj
opciona poverljivost kroz MWEB

Nije dobar izbor kada proizvod prvenstveno zahteva:

stabilnu fiat vrednost
kompleksne smart contract funkcije
trenutnu apsolutnu konačnost
univerzalnu podršku za poverljive transfere
chargeback mehanizam
potpuno pasivno održavanje infrastrukture

Najkorisniji način razmišljanja o Litecoinu nije „brži Bitcoin“ niti „stara kriptovaluta koja je još tu“. Za developera je to specijalizovan payment protokol sa poznatim UTXO modelom, dovoljno zrelom infrastrukturom i nekoliko zanimljivih kompromisa.

Njegova najveća prednost je što ne pokušava da bude sve. Njegova najveća mana je što današnje aplikacije često traže više od samog transfera vrednosti.

Ako se problem zaista svodi na primanje, potvrđivanje i slanje digitalnog novca, Litecoin ostaje tehnologija koju je relativno lako razumeti. Produkciona integracija ipak zahteva disciplinu oko ključeva, potvrda, reorganizacija, računovodstva i operativnog rizika. Upravo tu se završava demo, a počinje finansijski softver.

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

Ethereum iz ugla developera: EVM, gas i pametni ugovori

Dora Milen — Fri, 18 Sep 2026 01:38:55 +0000

Ethereum se često opisuje kao kriptovaluta, blockchain ili platforma za pametne ugovore. Sve tri tvrdnje su delimično tačne, ali developeru ne daju dovoljno precizan mentalni model.

Najkorisnije je posmatrati Ethereum kao javnu, distribuiranu state mašinu.

Postoji globalno stanje koje obuhvata naloge, njihove balanse, izvršni kod pametnih ugovora i podatke koje ti ugovori čuvaju. Transakcije predstavljaju ulaze u sistem. Ethereum Virtual Machine, odnosno EVM, deterministički izvršava te ulaze i proizvodi novo stanje. Hiljade nezavisnih računara zatim proveravaju da je prelazak iz starog u novo stanje urađen prema istim pravilima.

Rezultat nije naročito brz niti jeftin računar. Rezultat je računar čije stanje ne kontroliše jedan administrator, cloud nalog, kompanija ili baza podataka.

Upravo to je osnovna vrednost Ethereuma za developera.

Šta je Ethereum, precizno

Ethereum je decentralizovana mreža računara koji održavaju zajedničko stanje i izvršavaju programabilna pravila. Njegova nativna valuta je ether, sa oznakom ETH, ali ETH nije ceo sistem. ETH se koristi za plaćanje izvršavanja, zaštitu mreže kroz staking i prenos vrednosti između naloga.

Na običnom backendu funkcija može da promeni red u PostgreSQL tabeli:

HTTP zahtev -> aplikacija -> baza -> novo stanje

Na Ethereumu sličan tok izgleda ovako:

potpisana transakcija -> mreža -> EVM -> blok -> novo zajedničko stanje

Ključna razlika je u tome ko ima pravo da prihvati promenu.

U klasičnoj aplikaciji poslednju reč ima operator infrastrukture. Može promeniti bazu, vratiti backup, izmeniti autorizaciju ili ugasiti servis. Na Ethereumu pravila tranzicije stanja izvršava mreža nezavisnih čvorova. Operator jednog čvora ne može samostalno promeniti rezultat.

Ethereum zato ima smisla kada više strana treba da koristi isti sistem, ali nijedna strana ne bi trebalo da ima neograničenu administrativnu kontrolu nad njim.

To može biti:

razmena tokenizovane vrednosti
escrow između strana koje se međusobno ne poznaju
upravljanje zajedničkim treasuryjem
tržište digitalne imovine
sistem glasanja i izvršavanja odluka
registar vlasništva ili dozvola
dokaz da je određeni podatak postojao u određenom obliku
interoperabilni identitet i reputacija
finansijski protokol koji drugi ugovori mogu direktno koristiti

Ako aplikacija ima jednog vlasnika, jednu bazu i korisnike koji tom vlasniku veruju, blockchain često samo povećava složenost.

Ethereum nije distribuirani web server

Pametni ugovor nije zamena za REST API, Kubernetes cluster ili serverless funkciju.

EVM ima nekoliko važnih ograničenja:

izvršavanje se plaća
svi čvorovi moraju dobiti isti rezultat
ugovor ne može samostalno poslati HTTP zahtev
persistent storage je skup
javni podaci su vidljivi svima
potvrda promene nije trenutna
jednom objavljen kod nije jednostavno zameniti
greška može imati direktne finansijske posledice

Ethereum zato obično predstavlja samo jedan deo sistema.

Realna aplikacija često sadrži:

flowchart LR
    U[Browser ili mobilna aplikacija]
    W[Wallet]
    R[Ethereum JSON-RPC]
    C[Pametni ugovor]
    I[Indexer]
    D[Klasična baza]
    S[Objektni ili decentralizovani storage]

    U --> W
    W --> R
    R --> C
    C --> I
    I --> D
    U --> D
    U --> S

Frontend koristi wallet za autorizaciju i potpisivanje. RPC endpoint povezuje aplikaciju sa Ethereum čvorom. Pametni ugovor čuva minimalno kritično stanje. Indexer obrađuje događaje i gradi bazu pogodnu za pretragu. Veliki fajlovi i nekritični podaci ostaju van lanca.

To je hibridna arhitektura, a ne pokušaj da se cela aplikacija smesti u blockchain.

Globalno stanje i Ethereum nalozi

Ethereum poznaje dve osnovne vrste naloga:

Externally Owned Account, skraćeno EOA
contract account

EOA je tradicionalno kontrolisan privatnim ključem. Contract account je kontrolisan kodom koji se nalazi na njegovoj adresi.

Svaki nalog ima adresu i može posedovati ETH ili tokene. Međutim, samo nalog koji može autorizovati transakciju pokreće promenu globalnog stanja. Pametni ugovor se izvršava kada primi poziv u okviru već pokrenute transakcije.

Stanje naloga uključuje elemente kao što su:

nonce
ETH balans
hash izvršnog koda
root persistent storagea

nonce sprečava ponovno izvršavanje iste potpisane transakcije i određuje redosled transakcija jednog pošiljaoca.

Važno je razlikovati nalog od walleta. Nalog je deo Ethereum stanja. Wallet je softver ili hardverski uređaj koji upravlja ključevima i komunicira sa aplikacijama.

Savremeni Ethereum dodatno zamagljuje staru granicu između EOA i contract account modela. Transakcije tipa 4, uvedene kroz EIP-7702, omogućavaju EOA adresi da delegira izvršavanje postojećem kodu pametnog ugovora. To otvara prostor za batching, sponzorisanje naknada, recovery mehanizme i naprednije kontrole naloga.

Praktična posledica za autora ugovora je da ne treba pretpostavljati da je nalog bez trajno postavljenog koda nužno jednostavan korisnički nalog. Posebno je opasno zasnivati autorizaciju na pretpostavkama o tx.origin. Autorizacija treba da bude eksplicitna i dizajnirana tako da pozivalac može biti pametni ugovor. [2][3]

Kako izgleda Ethereum transakcija

Transakcija je kriptografski autorizovana instrukcija za promenu stanja.

Tipična transakcija sadrži:

chainId
nonce
adresu primaoca
količinu ETH koja se šalje
ulazne podatke
gas limit
parametre naknade
kriptografski potpis

Ako polje primaoca nije postavljeno, transakcija može predstavljati kreiranje novog ugovora. Ako je primalac EOA, najčešće se radi o prenosu ETH. Ako je primalac contract account, input određuje funkciju koja se poziva i njene argumente.

Ethereum koristi više tipova transakcija.

Tip	Namena
0	Legacy transakcija sa jednim `gasPrice` poljem
1	Transakcija sa access listom
2	Standardna EIP-1559 transakcija
3	Blob transakcija za rollup data availability
4	Transakcija sa EIP-7702 authorization listom

Za većinu aplikativnih transakcija wallet ili SDK formira odgovarajući tip. Developer ipak treba da razume polja, jer greške sa nonce, chainId, gas limitom ili parametrima naknade mogu dovesti do zaglavljenih, preplaćenih ili odbijenih transakcija.

Životni ciklus transakcije izgleda ovako:

Aplikacija konstruiše zahtev za transakciju.
Wallet prikazuje korisniku šta potpisuje.
Privatni ključ potpisuje serijalizovane podatke.
Potpisana transakcija šalje se Ethereum čvoru.
Čvor proverava potpis, nonce, balans i osnovnu validnost.
Transakcija ulazi u lokalni mempool i propagira se mrežom.
Validator je uključuje u execution payload bloka.
Ostali čvorovi ponovo izvršavaju transakciju.
Receipt postaje dostupan nakon uključivanja u blok.
Blok kasnije dobija status safe, a zatim finalized.

Slanje transakcije zato nije isto što i uspešno izvršavanje.

Dobijeni transaction hash znači da je zahtev prihvaćen za propagaciju, ne da je operacija završena. Aplikacija mora sačekati receipt i proveriti njegov status. Za operacije veće vrednosti može biti potrebno čekati dodatne potvrde ili finalizaciju. [3][5]

Šta se događa unutar Ethereum čvora

Ethereum čvor nije jedan monolitni proces. Njegova arhitektura sastoji se od najmanje dve povezane komponente:

execution client
consensus client

Execution client održava EVM stanje, prima transakcije, upravlja mempoolom i izvršava execution payload. Consensus client implementira proof-of-stake pravila, prati validatore, attestations, fork choice i finalizaciju.

Operator validatora obično pokreće i validator client koji upravlja validacionim ključevima i obavlja dužnosti predlaganja ili potvrđivanja blokova.

Tok bloka može se pojednostaviti ovako:

sequenceDiagram
    participant User
    participant EL as Execution client
    participant CL as Consensus client
    participant Validators
    participant Nodes

    User->>EL: Potpisana transakcija
    EL->>EL: Validacija i mempool
    CL->>EL: Zahtev za execution payload
    EL-->>CL: Transakcije i novo state stanje
    CL->>Validators: Predlog beacon bloka
    Validators->>Validators: Ponovno izvršavanje i attestations
    Validators->>Nodes: Propagacija prihvaćenog bloka

Ethereum vreme deli na slotove. Jedan slot traje 12 sekundi, a 32 slota čine jednu epohu. U svakom slotu bira se validator koji može predložiti blok, ali slot može ostati prazan ako izabrani validator ne obavi svoju dužnost.

Finalnost se utvrđuje glasanjem validatora o checkpointima na granicama epoha. Kada potrebna supervećina staked ETH podrži odgovarajuće checkpoint veze, stariji checkpoint postaje finalizovan.

Za frontend je često dovoljno prikazati transakciju nakon prvog uključenja u blok, uz jasno stanje poput pending, confirmed ili finalized. Backend koji poravnava račune, pušta sredstva ili pokreće nepovratnu eksternu operaciju treba da ima strožu politiku. [4][5]

EVM: deterministički runtime za pametne ugovore

Ethereum Virtual Machine izvršava bytecode pametnih ugovora.

EVM je stack mašina sa maksimalnom dubinom stacka od 1024 elementa. Osnovna reč je široka 256 bita, što odgovara kriptografskim operacijama i formatima koje Ethereum često koristi.

Tokom izvršavanja ugovor koristi nekoliko različitih prostora za podatke:

Prostor	Trajanje	Može se menjati	Tipična namena
Stack	Jedan execution frame	Da	Operandi EVM instrukcija
Memory	Jedan poziv	Da	Privremeni nizovi i strukture
Calldata	Jedan poziv	Ne	Argumenti funkcije
Storage	Trajno	Da	Stanje ugovora
Transient storage	Jedna transakcija	Da	Deljenje privremenog stanja između internih poziva
Logs	Trajno u receipt podacima	Ne iz ugovora	Događaji za offchain potrošače

Persistent storage je najskuplji jer promenu moraju obraditi i održavati čvorovi mreže. Zbog toga se na lancu ne čuvaju slike, dokumenti, kompletni JSON objekti ili veliki aplikativni zapisi ako za to ne postoji izuzetno dobar razlog.

Češći obrazac je:

podatak ostaje van lanca
na lancu se čuva njegov hash
ugovor čuva vlasništvo, status ili dozvolu
event beleži istoriju promene
indexer pravi model pogodan za frontend

EVM je deterministička. Ako dva ispravna čvora izvrše istu transakciju nad istim prethodnim stanjem, moraju dobiti isti rezultat. Zbog toga ugovor ne može direktno čitati vreme sa interneta, cenu sa berze ili rezultat sportskog meča.

block.timestamp dolazi iz samog bloka i može se koristiti samo kao približna vremenska referenca u granicama protokola. Podaci iz spoljnog sveta zahtevaju oracle ili drugi eksplicitni mehanizam za unos podataka. [6][7]

Pametni ugovor je javni program sa trajnim stanjem

Pametni ugovor je program postavljen na Ethereum adresu. Korisnici i drugi ugovori pozivaju njegove funkcije slanjem ABI kodiranih podataka.

Najpopularniji jezik je Solidity. Kompajler prevodi Solidity u:

EVM bytecode
deployment bytecode
ABI
metadata podatke

ABI opisuje funkcije, argumente, povratne vrednosti, događaje i greške. JavaScript biblioteka ne poziva Solidity funkciju direktno. Ona koristi ABI da napravi binarni calldata, šalje ga čvoru i dekodira rezultat.

Prva četiri bajta poziva funkcije predstavljaju selector:

keccak256("transfer(address,uint256)")[0:4]

Ostatak calldata sadrži ABI kodirane argumente.

Ovaj detalj postaje važan kada se analiziraju revertovi, proxy ugovori, multisig transakcije ili sirovi podaci iz block explorera.

Ugovori su međusobno kompozabilni. Jedan ugovor može pozvati drugi u istoj transakciji. Ako bilo koji poziv u lancu izvršavanja revertuje, promene se uglavnom vraćaju do odgovarajuće granice poziva.

To omogućava atomske operacije: više koraka može uspeti zajedno ili se cela operacija poništava.

Atomsko izvršavanje je jedna od najvažnijih osobina Ethereuma. Na klasičnom backendu isti rezultat često zahteva distribuirane transakcije, zaključavanje, compensating actions i koordinaciju između različitih servisa.

Gas: cena ograničenog izvršavanja

Gas je obračunska jedinica za količinu EVM rada.

Svaka instrukcija ima gas cenu. Čitanje memorije, hashiranje, pozivanje drugog ugovora i menjanje storagea ne koštaju isto. Transakcija navodi maksimalnu količinu gasa koju sme da potroši.

Stvarni trošak približno se računa kao:

trošak u ETH = gasUsed × effectiveGasPrice

Kod standardne EIP-1559 transakcije cena po jedinici gasa sastoji se od:

base fee
priority fee

Base fee određuje protokol na osnovu prethodnih blokova i spaljuje se. Priority fee predstavlja napojnicu validatoru. Pošiljalac postavlja i maxFeePerGas, čime ograničava koliko je spreman da plati.

Gas limit nije isto što i konačan trošak. To je gornja granica potrošnje. Neiskorišćen gas se ne naplaćuje kao izvršen gas.

Ako transakcija revertuje, već potrošen gas ostaje potrošen. Mreža je ipak morala da izvrši instrukcije kako bi ustanovila da operacija nije validna.

Koliko korišćenje Ethereuma košta

Ne postoji jedna tačna cena.

Trošak zavisi od:

mreže na kojoj se izvršava
trenutne potražnje za block spaceom
broja izvršenih EVM instrukcija
količine promenjenog storagea
veličine calldata
drugih ugovora koji se pozivaju
L1 data troška ako se koristi rollup

Pre slanja transakcije aplikacija treba da koristi procenu gasa, najčešće preko eth_estimateGas, i aktuelne podatke o naknadama. Procena nije garancija, jer se stanje može promeniti između simulacije i uključivanja u blok.

Trošak produkcionog sistema ne obuhvata samo gas. U budžet ulaze:

razvoj i testiranje ugovora
security review ili audit
RPC infrastruktura
indexer i baza
monitoring
upravljanje ključevima
multisig operacije
incident response
trošak nadogradnje i migracije

Za većinu aplikacija sa velikim brojem korisničkih transakcija direktno korišćenje Ethereum Mainneta nije ekonomski optimalno. Mainnet se češće koristi kao settlement i security sloj, dok se izvršavanje pomera na L2 mreže. [8]

Layer 2 nije odvojena tema

Ethereum scaling strategija zasniva se prvenstveno na rollup mrežama.

Rollup izvršava transakcije izvan Ethereum L1, grupiše rezultate i objavljuje podatke ili kriptografske dokaze na L1. Time se trošak deli između većeg broja korisnika.

Dve glavne porodice su:

optimistic rollups
zero-knowledge rollups

Optimistic rollup pretpostavlja da je objavljeni rezultat ispravan dok ga neko ne ospori u dozvoljenom periodu. ZK rollup objavljuje validity proof kojim dokazuje ispravnost tranzicije stanja.

Oba pristupa donose dodatne komponente:

sequencer
bridge ugovore
batch objavljivanje
poseban model finalnosti
različite mehanizme izlaska
dodatni rizik implementacije i upravljanja

Blob transakcije uvedene kroz EIP-4844 omogućile su rollup mrežama da jeftinije objavljuju privremene podatke na Ethereum. Kasniji PeerDAS mehanizam omogućava čvorovima da uzorkuju delove blob podataka umesto da svaki čvor preuzima svaki blob u celosti. Kapacitet blobova može se prilagođavati kroz posebne promene parametara bez čekanja kompletnog velikog upgradea. [9][10]

Za aplikativnog developera odluka zato nije samo „Ethereum ili nešto drugo“. Realniji izbor je:

Ethereum L1
general-purpose Ethereum L2
application-specific rollup
centralizovani backend
kombinacija navedenih sistema

L2 može smanjiti naknade, ali ne uklanja potrebu da razumete bridge rizik, dostupnost sequencera, finalnost i razliku između L2 potvrde i L1 settlementa.

Realan use-case: registar softverskih artefakata

Zamislimo nekoliko kompanija koje zajednički koriste softverske pakete. Svaka kompanija objavljuje build artefakte, ali nijedna ne želi da druga strana bude jedini administrator registra.

Cilj nije da se ZIP, container image ili SBOM smeste na Ethereum. To bi bilo skupo i nepraktično.

Na lancu se mogu čuvati:

identitet publishera
hash artefakta
hash metapodataka
identifikator izdanja
vreme objavljivanja

Sam artefakt može ostati u object storageu, container registryju ili content-addressed mreži. Potrošač pre deploymenta računa hash preuzetog fajla i poredi ga sa hashom koji je publisher zabeležio na lancu.

Minimalni ugovor može izgledati ovako:

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

contract ReleaseRegistry {
    struct Release {
        bytes32 artifactDigest;
        bytes32 metadataDigest;
        uint64 publishedAt;
    }

    mapping(bytes32 => Release) private releases;

    error EmptyDigest();
    error AlreadyPublished(bytes32 key);

    event ReleasePublished(
        bytes32 indexed key,
        address indexed publisher,
        bytes32 indexed releaseId,
        bytes32 artifactDigest,
        bytes32 metadataDigest
    );

    function keyFor(
        address publisher,
        bytes32 releaseId
    ) public pure returns (bytes32) {
        return keccak256(abi.encode(publisher, releaseId));
    }

    function publish(
        bytes32 releaseId,
        bytes32 artifactDigest,
        bytes32 metadataDigest
    ) external returns (bytes32 key) {
        if (
            artifactDigest == bytes32(0) ||
            metadataDigest == bytes32(0)
        ) {
            revert EmptyDigest();
        }

        key = keyFor(msg.sender, releaseId);

        if (releases[key].publishedAt != 0) {
            revert AlreadyPublished(key);
        }

        releases[key] = Release({
            artifactDigest: artifactDigest,
            metadataDigest: metadataDigest,
            publishedAt: uint64(block.timestamp)
        });

        emit ReleasePublished(
            key,
            msg.sender,
            releaseId,
            artifactDigest,
            metadataDigest
        );
    }

    function get(
        address publisher,
        bytes32 releaseId
    )
        external
        view
        returns (
            bytes32 artifactDigest,
            bytes32 metadataDigest,
            uint64 publishedAt
        )
    {
        Release memory release = releases[
            keyFor(publisher, releaseId)
        ];

        return (
            release.artifactDigest,
            release.metadataDigest,
            release.publishedAt
        );
    }
}

Ovaj ugovor namerno ne pokušava da rešava sve.

Nema globalnog administratora, upgrade mehanizma, liste odobrenih publishera ni revocation modela. Namespace svakog izdanja vezan je za adresu publishera, tako da dve organizacije mogu koristiti isti releaseId bez konflikta.

U produkcionom sistemu trebalo bi definisati:

kako se publisher adrese registruju
da li publisher koristi multisig
kako se rotiraju kompromitovani ključevi
može li se izdanje opozvati
ko može objaviti revocation
koji hash algoritam i canonical format se koriste
šta tačno znači metadataDigest
šta se dešava ako storage sa artefaktom postane nedostupan
da li L2 pruža dovoljan nivo sigurnosti za konkretan slučaj

Blockchain potvrđuje da je određena adresa objavila određeni digest. Ne potvrđuje da je softver bezbedan, da publisher ima dobru reputaciju ili da je privatni ključ korišćen od strane prave osobe.

To je važna granica sistema.

Integracija iz JavaScript aplikacije

Ethereum execution client izlaže JSON-RPC interfejs. Biblioteke poput ethers.js obavijaju RPC metode i koriste ABI za kodiranje poziva.

Za čitanje ugovora dovoljan je provider. Za promenu stanja potreban je signer.

Skraćena browser integracija može izgledati ovako:

import {
    BrowserProvider,
    Contract,
    id,
    keccak256,
    toUtf8Bytes
} from "ethers";

const registryAddress = "0x...";
const registryAbi = [
    "function publish(bytes32,bytes32,bytes32) returns (bytes32)",
    "function get(address,bytes32) view returns " +
        "(bytes32,bytes32,uint64)"
];

const provider = new BrowserProvider(window.ethereum);
const signer = await provider.getSigner();

const registry = new Contract(
    registryAddress,
    registryAbi,
    signer
);

const file = document.querySelector("input[type=file]").files[0];
const artifactBytes = new Uint8Array(await file.arrayBuffer());

const releaseId = id("@example/api@2.4.0");
const artifactDigest = keccak256(artifactBytes);

// Ovaj string mora biti napravljen determinističkom
// canonical JSON procedurom.
const canonicalMetadata =
    '{"commit":"8fd5...","platform":"linux-amd64"}';

const metadataDigest = keccak256(
    toUtf8Bytes(canonicalMetadata)
);

const tx = await registry.publish(
    releaseId,
    artifactDigest,
    metadataDigest
);

const receipt = await tx.wait();

console.log({
    transactionHash: receipt.hash,
    blockNumber: receipt.blockNumber
});

Korišćenje običnog JSON.stringify nije dovoljno ako različiti sistemi mogu proizvesti drugačiji redosled ključeva ili različitu reprezentaciju istih podataka. Pre hashiranja treba definisati canonical format i tretirati ga kao deo protokola.

Za backend čitanje koristi se JsonRpcProvider:

import { Contract, JsonRpcProvider, id } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);

const registry = new Contract(
    process.env.REGISTRY_ADDRESS,
    [
        "function get(address,bytes32) view returns " +
            "(bytes32,bytes32,uint64)"
    ],
    provider
);

const releaseId = id("@example/api@2.4.0");

const [
    artifactDigest,
    metadataDigest,
    publishedAt
] = await registry.get(
    process.env.PUBLISHER_ADDRESS,
    releaseId
);

console.log({
    artifactDigest,
    metadataDigest,
    publishedAt: Number(publishedAt)
});

view poziv se obično izvršava preko eth_call. On ne menja stanje i korisnik ne šalje transakciju, pa nema onchain gas naknade. RPC provider i dalje može imati infrastrukturna ograničenja ili sopstveni model naplate.

State-changing poziv kreira transakciju, zahteva potpis i troši gas. [11][12]

Zašto frontend ne treba da koristi blockchain kao bazu

Moguće je pozivati getter funkcije za svaki ekran, ali to retko predstavlja dobru produkcionu arhitekturu.

JSON-RPC je pogodan za:

proveru aktuelnog stanja
simulaciju poziva
dobijanje receipt podataka
slanje potpisanih transakcija
čitanje manjeg broja ugovora i logova

Nije idealan za složene upite poput:

sva izdanja publishera sortirana po datumu
pretraga po delu naziva
statistika aktivnosti u poslednjih 90 dana
spajanje podataka iz više ugovora
full-text search
filtriranje po offchain metapodacima

Za to se koriste events i indexer.

Ugovor emituje ReleasePublished. Indexer prati blokove, dekodira događaj pomoću ABI-ja i upisuje rezultat u PostgreSQL ili drugi query-friendly sistem.

Indexer mora da obrađuje:

privremene chain reorganizacije
ponovno procesiranje blokova
idempotentne upise
pomeranje safe i finalized heada
promene adrese ugovora
ABI verzije
nestanak ili ograničenje RPC providera

Baza indexera predstavlja izvedeni prikaz blockchain stanja. Ako se ošteti, može se ponovo izgraditi iz logova, pod uslovom da postoji pristup potrebnoj istoriji.

Razvojni workflow koji liči na ozbiljan softver

Pametan ugovor ne bi trebalo prvo pisati u browser editoru, a zatim odmah objaviti na Mainnetu.

Razumniji tok je:

Definisati trust model.
Odvojiti onchain od offchain odgovornosti.
Formalizovati invariants.
Implementirati najmanji potreban ugovor.
Pisati unit i fuzz testove.
Testirati neuspešne i zlonamerne pozive.
Pokrenuti sistem na lokalnoj development mreži.
Deployovati na Sepolia testnet.
Integrisati frontend, backend i indexer.
Simulirati migraciju i incident response.
Verifikovati source code ugovora.
Sprovesti nezavisan security review.
Tek zatim razmatrati produkcionu mrežu.

Sepolia je preporučeni javni testnet za razvoj ugovora i aplikacija. Hoodi je namenjen prvenstveno protokolskom razvoju i testiranju validatora. Testnet ETH nema istu ekonomsku vrednost kao Mainnet ETH i ne treba koristiti iste naloge i privatne ključeve u oba okruženja. [13]

Unit testovi treba da provere očekivano ponašanje. Fuzz testovi treba da pokušaju da pronađu ulaze koji krše invariants.

Za prethodni registar neki od invariants mogu biti:

objavljen digest se ne može prepisati
jedan publisher ne može menjati namespace drugog publishera
prazan digest se nikada ne upisuje
emitovani event odgovara upisanom stanju
funkcija keyFor uvek vraća isti rezultat za iste ulaze

Testiranje samo happy patha nije dovoljno. Napadač bira ulaze, redosled poziva i ugovore koji učestvuju u transakciji.

Najčešće greške klasičnih developera

Pretpostavka da je `private` podatak tajan

Solidity oznaka private ograničava pristup iz drugih ugovora na nivou jezika. Podatak u storageu i dalje je vidljiv svakome ko čita blockchain.

Lozinke, API ključevi, privatni dokumenti i nešifrovani lični podaci ne pripadaju javnom blockchainu.

Korišćenje `tx.origin` za autorizaciju

tx.origin predstavlja originalni EOA na početku lanca poziva, ne neposrednog pozivaoca. Autorizacija zasnovana na njemu može biti ranjiva i nije kompatibilna sa savremenim modelima pametnih naloga.

Koristite eksplicitne role, msg.sender, potpise ili dobro definisan authorization sloj.

Neproveravanje povratne vrednosti low-level poziva

call, delegatecall i staticcall imaju specifično ponašanje. Low-level call vraća status koji aplikacija mora proveriti. Pogrešna upotreba delegatecall može omogućiti izvršavanje stranog koda u storage kontekstu pozivaoca.

External call pre izmene lokalnog stanja

Ako ugovor šalje kontrolu drugom ugovoru pre ažuriranja sopstvenog stanja, druga strana može pokušati reentrant poziv.

Checks-effects-interactions obrazac, pull payments i odgovarajući guard mehanizmi smanjuju rizik, ali ne zamenjuju razumevanje celog call grapha.

Neograničene petlje nad rastućim storageom

Petlja koja prolazi kroz sve korisnike možda radi u testu sa deset naloga, ali može postati neizvršiva kada lista poraste. Gas limit bloka predstavlja hardversko i protokolsko ograničenje.

Iteraciju je često bolje pomeriti u indexer ili podeliti u više ograničenih transakcija.

Slepo kopiranje token ili proxy implementacija

Standardi poput ERC-20 opisuju interfejs i očekivano ponašanje, ali ne rešavaju automatski autorizaciju, supply politiku, upgrade administraciju ili ekonomsku sigurnost.

Za standardne komponente prednost imaju proverene biblioteke iz objavljenih paketa. Kopiranje delova biblioteke u sopstveni projekat otežava praćenje verzija i bezbednosnih ispravki.

Mešanje uključenja u blok i finalnosti

Receipt potvrđuje da je transakcija uključena u određeni blok. Ne znači da je blok već finalizovan.

Sistem treba da definiše koliko potvrda čeka i koje operacije zahteva da blok bude safe ili finalized.

Upgradeable ugovor bez plana upravljanja

Proxy omogućava promenu implementacije, ali uvodi privilegovani upgrade ključ, storage layout rizik i mogućnost da administrator promeni pravila sistema.

„Upgradeable“ nije isto što i „bezbednije“. To je drugačiji trust model koji mora biti vidljiv korisnicima.

Operativna bezbednost je deo aplikacije

Sigurnost pametnog ugovora ne završava se kada Solidity kod prođe audit.

Produkcioni sistem mora zaštititi:

deployer ključ
upgrade administratora
treasury
oracle naloge
relayer ključeve
RPC credentials
CI/CD pipeline
package registry
DNS i frontend
indexer infrastrukturu

Privilegovane operacije ne bi trebalo držati iza jednog browser walleta zaposlenog. Multisig, hardverski walleti, jasno odvojene role i timelock mehanizmi omogućavaju kontrolisaniji operativni model.

Događaje koji menjaju kritične parametre treba pratiti offchain. Monitoring može upozoriti na:

promenu administratora
upgrade implementacije
neuobičajeno veliki transfer
pauziranje protokola
dodelu privilegovane role
promenu oracle izvora
neočekivanu učestalost poziva

Jednostavniji ugovor obično ima manju površinu napada. Modularnost je korisna, ali svaki dodatni proxy, bridge, oracle ili governance sloj uvodi nove failure modeove. [14]

Kada Ethereum ima smisla

Ethereum je dobar kandidat kada su istovremeno važni:

zajedničko stanje između nezavisnih strana
javna proverljivost
programabilna pravila
otpornost na jednostranu administrativnu izmenu
digitalna imovina ili prava koja ugovor direktno kontroliše
interoperabilnost sa postojećim ugovorima i tokenima
mogućnost da korisnik sam čuva i autorizuje svoju imovinu

Naročito je koristan kada aplikacija ne bi trebalo da bude samo proizvod jedne kompanije, već protokol koji mogu koristiti drugi proizvodi.

Pametni ugovor tada liči na javni backend čija pravila, stanje i istoriju mogu proveriti svi učesnici.

Kada ga ne treba koristiti

Ethereum verovatno nije odgovarajući izbor ako:

aplikacija zahteva privatne podatke u osnovnom modelu
jedan operator već ima legitimno puno ovlašćenje
transakcije moraju biti besplatne i trenutno potvrđene
podaci se često menjaju i nemaju dugoročnu vrednost
potreban je intenzivan CPU ili storage workload
poslovna pravila moraju često i nepredvidivo da se menjaju
korisnici ne mogu upravljati ključevima niti koristiti posredovani wallet
nema realne potrebe za nezavisnom proverom stanja

Blockchain ne uklanja poverenje. On ga preraspoređuje.

Umesto poverenja u jednog administratora, sistem može zahtevati poverenje u kod ugovora, governance, oracle, wallet, bridge, sequencer, frontend i upravljanje ključevima. Dobar dizajn jasno opisuje svaku od tih pretpostavki.

Šta developer zapravo dobija

Ethereum nije privlačan zato što predstavlja neobičan način čuvanja podataka. Njegova vrednost je u kombinaciji nekoliko osobina:

izvršavanje je determinističko
stanje je javno proverljivo
transakcije su kriptografski autorizovane
pravila su programabilna
ugovori su međusobno kompozabilni
digitalna imovina može biti deo samog execution modela
više koraka može se izvršiti atomski
aplikacija može biti dostupna nezavisno od jednog backend operatora

Cena tih osobina su složeniji razvoj, ograničen throughput, promenljive naknade, javnost podataka i mnogo veća odgovornost za bezbednost.

Najbolji način da se razume Ethereum nije pravljenje još jednog tokena. Korisniji eksperiment je uzeti mali problem sa jasnom trust granicom, zapisati jedno kritično stanje u ugovor i izgraditi ostatak sistema kao normalnu aplikaciju.

Tek tada postaje očigledno šta pripada blockchainu, a šta nikada nije trebalo stavljati na njega.

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

Bitcoin iz ugla developera: protokol, čvorovi i kod

Dora Milen — Fri, 18 Sep 2026 00:41:39 +0000

Bitcoin se često opisuje kao digitalni novac, kriptovaluta, investicija ili blockchain. Sve su to korisne prečice, ali nijedna ne objašnjava šta sistem zapravo radi.

Iz ugla developera, Bitcoin je distribuirani protokol za održavanje zajedničkog skupa nepotrošenih izlaza transakcija. Učesnici ne moraju da veruju centralnom serveru, administratoru baze ili procesoru plaćanja. Umesto toga, svaki potpuno validirajući čvor može samostalno da proveri istoriju, pravila izdavanja i svaku promenu stanja.

To ne znači da je Bitcoin bez poverenja u apsolutnom smislu. I dalje verujete sopstvenom softveru, operativnom sistemu, hardveru, načinu na koji ste dobili binarne fajlove i sopstvenoj implementaciji poslovne logike. Ključna razlika je u tome što protokol omogućava nezavisnu proveru umesto obaveznog oslanjanja na jednu instituciju.

Za developera je zato Bitcoin zanimljiviji kao sistem nego kao tržišna cena. U njemu se ukrštaju distribuirani sistemi, kriptografija, mrežni protokoli, upravljanje ključevima, baze podataka, eventualna konzistentnost i neprijateljsko okruženje u kojem svaki ulaz mora da se tretira kao nepoverljiv.

Šta je Bitcoin, precizno

Bitcoin obuhvata nekoliko povezanih pojmova:

Bitcoin je protokol koji definiše validne transakcije i blokove.
Bitcoin je peer-to-peer mreža čvorova koji razmenjuju transakcije i blokove.
Bitcoin je javna istorija potvrđenih transakcija organizovanih u lanac blokova.
bitcoin, odnosno BTC, jeste obračunska jedinica tog sistema.
Bitcoin Core je jedna implementacija protokola, ujedno najčešće korišćena za potpuno validirajuće čvorove.

Ne postoji centralni Bitcoin server. Ne postoji jedna zvanična baza koju svi klijenti pozivaju. Ne postoji administratorski endpoint koji može da promeni stanje naloga.

Čvorovi komuniciraju preko peer-to-peer mreže, ali svaki čvor lokalno odlučuje da li su primljeni podaci validni. Ako peer pošalje blok koji stvara nedozvoljenu količinu bitcoina ili troši nepostojeći izlaz, ispravan čvor ga odbacuje bez obzira na to koliko je rada uloženo u taj blok.

Bitcoin se zbog toga može posmatrati kao deterministički validator okružen nedeterminističkom mrežom. Redosled prijema poruka, skup peerova i sadržaj lokalnog mempoola mogu da se razlikuju. Pravila validacije iste transakcije ili bloka moraju da daju isti rezultat na svim kompatibilnim čvorovima.

Bitcoin nema naloge ni stanje računa

Jedna od prvih konceptualnih prepreka jeste to što Bitcoin ne koristi model naloga kakav postoji u banci ili većini poslovnih aplikacija.

Ne postoji zapis poput:

alice.balance = 1.5 BTC

Umesto toga, Bitcoin koristi UTXO model. UTXO je skraćenica za unspent transaction output, odnosno nepotrošeni izlaz transakcije.

Svaka transakcija:

troši jedan ili više prethodnih izlaza,
kreira jedan ili više novih izlaza,
implicitno plaća naknadu kao razliku između ukupnih ulaza i izlaza.

Pojednostavljen prikaz izgleda ovako:

Ulazi:
  prethodni izlaz A: 80.000 sat
  prethodni izlaz B: 50.000 sat

Izlazi:
  primalac:           100.000 sat
  kusur:               28.500 sat

Naknada:
  1.500 sat

Jedan bitcoin deli se na 100.000.000 satoshija. Konsenzus i Bitcoin Core interno rade sa celobrojnim iznosima najmanje jedinice, a ne sa decimalnim floating-point vrednostima. Finansijski kod koji BTC iznose čuva kao float ili double uvodi nepotreban rizik zaokruživanja.

Formalno, za validnu običnu transakciju važi:

zbir ulaza >= zbir izlaza
naknada = zbir ulaza - zbir izlaza

Svaki ulaz referencira prethodnu transakciju pomoću njenog identifikatora i indeksa izlaza, često predstavljenih kao txid:vout. Ulaz zatim pruža podatke potrebne da zadovolji uslov trošenja tog izlaza.

Kada korisnički interfejs prikazuje balans novčanika, on zapravo sabira UTXO izlaze koje novčanik ume da potroši ili prati.

To ima praktične posledice:

Jedna uplata ne menja numeričko polje na računu, već kreira novi UTXO.
Za plaćanje većeg iznosa novčanik može da kombinuje više UTXO-a.
Ako je izabrani UTXO veći od plaćanja, kreira se izlaz za kusur.
Veći broj ulaza obično znači veću transakciju i višu naknadu.
Dva korisnika sa istim balansom mogu imati veoma različite troškove sledećeg plaćanja.

UTXO selekcija zato nije trivijalan detalj novčanika. Ona utiče na naknade, privatnost, fragmentaciju sredstava i mogućnost budućeg trošenja.

Šta se nalazi u transakciji

Bitcoin transakcija sadrži verziju, ulaze, izlaze i polje za vremensko zaključavanje. Kod SegWit transakcija postoje i odvojeni witness podaci.

Svaki ulaz tipično sadrži:

identifikator prethodne transakcije,
indeks prethodnog izlaza,
podatke za otključavanje ili odgovarajući witness,
sequence vrednost.

Svaki izlaz sadrži:

iznos u satoshijima,
scriptPubKey, odnosno program koji definiše uslov budućeg trošenja.

Adresa nije deo protokola na isti način kao transakcioni izlaz. Ona je korisnički format za kodiranje informacija iz kojih novčanik konstruiše odgovarajući scriptPubKey.

To znači da bitcoin nije bukvalno „poslat na adresu“. Transakcija kreira izlaz sa uslovom trošenja. Novčanik primaoca poseduje ili može da proizvede podatke potrebne za zadovoljenje tog uslova.

Najčešći savremeni formati uključuju:

SegWit izlaze sa adresama koje obično počinju sa bc1q na glavnoj mreži,
Taproot izlaze sa adresama koje obično počinju sa bc1p,
starije formate koji ostaju validni, ali nisu uvek najbolji izbor za nove integracije.

Aplikacija ne bi trebalo da validira Bitcoin adresu samo regularnim izrazom. Potrebno je proveriti mrežu, checksum, verziju witness programa, dužinu i pravila konkretnog formata.

Script nije pametni ugovor opšte namene

Uslovi trošenja izražavaju se pomoću Bitcoin Script jezika. To je ograničen, stack-based jezik projektovan tako da validacija bude deterministička i kontrolisana.

Tipičan uslov u suštini kaže: „Pokaži validan digitalni potpis koji odgovara ovom javnom ključu.“

Složeniji uslovi mogu zahtevati:

potpise više ključeva,
čekanje do određene visine bloka,
čekanje određene količine vremena,
otkrivanje preimage vrednosti za poznati hash,
kombinaciju više pravila.

Bitcoin Script nije zamišljen kao virtuelna mašina za pokretanje proizvoljnih aplikacija. Nema klasične neograničene petlje i namerno je restriktivan. Njegov primarni posao je autorizacija trošenja, ne hostovanje opšteg aplikativnog stanja.

Taproot je unapredio način na koji se predstavljaju ključevi i složeni uslovi. Omogućava trošenje preko ključa, kao i otkrivanje samo izvršene grane skripte kada je potreban script path. Time složene politike mogu biti efikasnije i privatnije, pod uslovom da su pravilno projektovane.[1]

Privatni ključ nije lozinka koju možete resetovati

Vlasništvo nad bitcoinom u praksi znači mogućnost stvaranja validnog potpisa za određeni izlaz.

Privatni ključ je tajni broj iz dozvoljenog opsega krive secp256k1. Iz njega se izvodi javni ključ. Potpis dokazuje da potpisnik poseduje privatni ključ, bez objavljivanja samog ključa.

Bitcoin koristi ECDSA potpise za starije tipove izlaza i Schnorr potpise definisane za Taproot.

Privatni ključ nije:

nalog na serveru,
šifra koju servis može da promeni,
podatak koji treba poslati API-ju treće strane,
vrednost koju je bezbedno zapisati u log.

Ako se ključ izgubi bez rezervne kopije, ne postoji centralna procedura za oporavak. Ako ga neko kopira, originalni vlasnik ne dobija obaveštenje. Napadač može potpisati transakciju i sredstva poslati na sopstveni izlaz.

Zbog toga ozbiljan novčanik obično ne upravlja gomilom nasumičnih, nepovezanih ključeva. Hijerarhijski deterministički novčanici izvode veliki broj ključeva iz početnog tajnog materijala. Descriptor novčanici dodatno eksplicitno opisuju koje skripte i ključeve novčanik prati.[2]

Seed fraza je samo jedna moguća reprezentacija tajnog materijala. Ona nije bitcoin na papiru. Bitcoin ostaje zabeležen kroz UTXO skup, dok seed omogućava rekonstrukciju ključeva potrebnih za trošenje.

Kako transakcija stiže do potvrde

Životni ciklus jedne transakcije približno izgleda ovako:

flowchart LR
    A[Novčanik bira UTXO-e] --> B[Formira izlaze i kusur]
    B --> C[Izračunava naknadu]
    C --> D[Potpisuje ulaze]
    D --> E[Šalje transakciju peerovima]
    E --> F[Čvorovi je validiraju]
    F --> G[Lokalni mempool]
    G --> H[Rudar je uključuje u blok]
    H --> I[Čvorovi proveravaju blok]
    I --> J[Potvrđena transakcija]

Novčanik najpre bira UTXO-e koje će potrošiti. Zatim formira izlaz za primaoca, eventualni izlaz za kusur i odgovarajuću naknadu. Nakon potpisivanja šalje serijalizovanu transakciju jednom ili više čvorova.

Čvor proverava, između ostalog:

da li je format transakcije ispravan,
da li referencirani izlazi postoje i nisu već potrošeni,
da li potpisi i skripte prolaze validaciju,
da li su iznosi u dozvoljenim granicama,
da li je transakcija finalna prema pravilima zaključavanja,
da li zadovoljava lokalnu relay politiku.

Ako je prihvati, čvor je obično smešta u svoj mempool i prosleđuje peerovima.

Važno je da ne postoji jedan globalni mempool. Svaki čvor ima sopstveni pogled na nepotvrđene transakcije. Mempool može da se razlikuje zbog vremena prijema, konfiguracije, minimalne naknade, zamene transakcija i ograničenja memorije.

Status „nalazi se u mempoolu“ zato nije konsenzusna činjenica. To je lokalno zapažanje jednog čvora.

Šta rudari zapravo rade

Rudari biraju transakcije, konstruišu kandidata za blok i pokušavaju da pronađu validan proof of work.

Blok sadrži zaglavlje i listu transakcija. Zaglavlje ima 80 bajtova i uključuje:

verziju,
hash prethodnog bloka,
Merkle root transakcija,
vremensku oznaku,
kodirani cilj težine,
nonce.

Rudar menja nonce i druge promenljive u kandidatu, računa dvostruki SHA-256 hash zaglavlja i traži rezultat manji od trenutnog cilja.

Proof of work ne dokazuje da je blok validan. On dokazuje da je uložen očekivani računarski rad. Čvor i dalje proverava sve transakcije i sva konsenzusna pravila.

Ovo razdvaja dve uloge koje se često pogrešno spajaju:

Rudari predlažu redosled validnih transakcija i ulažu rad.
Čvorovi odlučuju da li predloženi blok poštuje pravila koja oni izvršavaju.

Rudar ne može da natera ispravan čvor da prihvati nevalidnu transakciju. Može da bira koje validne transakcije će uključiti, može privremeno da ih cenzuriše u sopstvenim blokovima i može da pokuša reorganizaciju lanca, ali ne može jednostrano da promeni pravila validacije.

Odakle dolazi novi bitcoin

Prva transakcija u svakom bloku je coinbase transakcija. Ona nema standardne ulaze i omogućava rudaru da potražuje:

trenutno dozvoljenu subvenciju bloka,
zbir naknada svih drugih transakcija u bloku.

Subvencija se periodično prepolovljava prema unapred definisanom rasporedu. Time se tempo izdavanja smanjuje, a ukupna količina konvergira ka granici nešto manjoj od 21 milion BTC.

Čvorovi proveravaju da coinbase ne stvara više nego što je dozvoljeno. Rudar može potraživati manje, ali ne može naterati validirajuće čvorove da prihvate veću nagradu.

Coinbase izlazi imaju dodatno pravilo zrelosti. Ne mogu se odmah potrošiti, što postaje vidljivo i pri radu na lokalnoj regtest mreži.

Kako mreža bira istoriju

Fraza „najduži lanac“ je praktična, ali nije sasvim precizna. Čvor bira validan lanac sa najvećim kumulativnim dokazanim radom, odnosno najvećim chainwork-om.

Ponekad dva rudara pronađu različite validne blokove približno istovremeno. Deo mreže prvo vidi jedan, a deo drugi blok. Kada se pojavi naredni blok, jedna grana obično dobija više kumulativnog rada i postaje aktivna.

Tada može doći do reorganizacije. Transakcija iz napuštene grane može:

ponovo postati nepotvrđena,
biti potvrđena u novoj grani,
postati konfliktna ako druga transakcija troši iste ulaze.

Bitcoin zato nema trenutnu apsolutnu finalnost. Svaki dodatni blok iznad transakcije povećava cenu reorganizacije, ali ne proizvodi matematički trenutak posle kojeg je reorganizacija nemoguća.

Broj potrebnih potvrda treba vezati za rizik:

Digitalni sadržaj male vrednosti može tolerisati nepotvrđenu uplatu.
Roba koja još nije poslata može čekati jednu ili nekoliko potvrda.
Velika i nepovratna isporuka zahteva konzervativniju politiku.
Sistem mora ostati korektan čak i ako se već viđena potvrda privremeno izgubi.

Fiksno pravilo „šest potvrda za sve“ lakše je implementirati, ali nije uvek dobro modelovanje poslovnog rizika.

Konsenzusna pravila i relay politika nisu isto

Bitcoin Core razlikuje pravila konsenzusa od lokalne politike prihvatanja i prosleđivanja nepotvrđenih transakcija.

Konsenzusna pravila određuju da li transakcija sme da bude deo validnog bloka. Relay politika određuje da li će konkretan čvor nepotvrđenu transakciju prihvatiti u mempool i proslediti dalje.

Transakcija može biti konsenzusno validna, ali nestandardna prema politici određenog čvora. Takva transakcija nije nužno zabranjena u bloku, ali može biti teško distribuirana kroz mrežu.

Za aplikativnog developera ovo znači da „lokalni RPC je prihvatio transakciju“ i „transakcija će pouzdano stići do rudara“ nisu potpuno ista tvrdnja.

Politike se mogu menjati između verzija softvera. Integracija koja zavisi od graničnog mempool ponašanja mora se testirati sa verzijom i konfiguracijom koja će zaista biti korišćena.

Koliko Bitcoin transakcija košta

Bitcoin protokol nema fiksnu cenu transakcije i naknada nije procenat poslatog iznosa.

Naknada zavisi od dve stvari:

naknada = feerate × virtuelna veličina transakcije

feerate se obično izražava u satoshijima po virtuelnom bajtu, odnosno sat/vB.

Virtuelna veličina zavisi od strukture transakcije:

broja i tipa ulaza,
broja i tipa izlaza,
vrste skripti,
količine witness podataka.

Transakcija koja šalje malu vrednost može biti skuplja od transakcije velike vrednosti ako troši mnogo malih UTXO-a.

Tržište naknada nastaje zato što je prostor u blokovima ograničen. Kada mnogo korisnika želi brzo potvrđivanje, rudari uglavnom biraju transakcije sa većim efektivnim feerate-om.

Bitcoin Core nudi procenu naknade preko RPC metode estimatesmartfee, ali rezultat je procena zasnovana na prethodnom ponašanju mreže, ne garancija vremena potvrde.[3]

Ukupan trošak integracije može uključivati i:

mrežnu naknadu za povlačenje ili konsolidaciju UTXO-a,
infrastrukturu i skladište za sopstveni čvor,
bandwidth tokom početne sinhronizacije,
održavanje rezervnih kopija i sistema za ključeve,
naknade ili spread posredničkog servisa,
računovodstvene i regulatorne troškove.

Aktuelna Bitcoin Core dokumentacija navodi da potpuna početna sinhronizacija zahteva preuzimanje stotina gigabajta podataka. Pruning može znatno smanjiti trajno zauzeće diska, ali pruned čvor ne može kasnije da posluži sve stare blokove bez ponovnog preuzimanja.[4]

SegWit, težina i zašto veličina nije samo broj bajtova

Segregated Witness odvaja podatke potpisa od osnovnog dela transakcije i uvodi obračun težine. Zbog toga se naknade u korisničkim interfejsima često računaju preko virtuelnih bajtova, a ne proste serijalizovane veličine.

SegWit takođe razlikuje:

txid, identifikator izračunat bez witness dela,
wtxid, identifikator koji uključuje witness podatke.

Ovo je važno kada indeksirate transakcije, gradite explorer ili pratite objekte pre potvrde.

SegWit je rešio praktične probleme sa klasičnom transakcionom malleability i omogućio efikasnije protokole višeg sloja. Nije samo novi format adrese.[5]

Replace-by-fee i ubrzavanje transakcija

Pošiljalac može napraviti novu verziju nepotvrđene transakcije sa većom naknadom ako su ispunjeni odgovarajući uslovi politike. Ovaj mehanizam se obično naziva replace-by-fee ili RBF.

Druga tehnika je child-pays-for-parent. Nova transakcija troši izlaz nepotvrđene roditeljske transakcije i dodaje dovoljno visoku naknadu da paket bude privlačan za uključivanje u blok.

Za payment backend iz toga slede dva važna pravila:

Nepotvrđena transakcija nije konačan objekat samo zato što imate njen txid.
Poslovna logika mora da prati konflikte, zamene i potrošnju očekivanih izlaza.

Ako proizvod prihvata zero-confirmation plaćanja, to je eksplicitno preuzimanje rizika radi boljeg korisničkog iskustva. Nije svojstvo protokola koje garantuje naplatu.

Full node, lagani klijent ili tuđi API

Postoje tri uobičajena načina da aplikacija sazna šta se dešava na Bitcoin mreži.

Sopstveni potpuno validirajući čvor

Aplikacija komunicira sa Bitcoin Core čvorom preko lokalnog ili privatnog JSON-RPC interfejsa.

Prednosti:

samostalna validacija konsenzusnih pravila,
nema zavisnosti od tuđeg prikaza blockchaina,
bolja kontrola privatnosti,
direktan pristup mempoolu, blokovima i wallet funkcijama.

Nedostaci:

početna sinhronizacija,
disk, bandwidth i operativno održavanje,
potreba za praćenjem verzija i bezbednosnih objava,
sopstveno rešavanje dostupnosti i indeksiranja.

Lagani klijent

Lagani klijent ne preuzima i ne validira sve podatke na isti način kao full node. Može koristiti zaglavlja blokova i kompaktne filtere kako bi pronašao potencijalno relevantne transakcije.

To smanjuje zahteve uređaja, ali menja model poverenja, privatnosti i dostupnosti podataka. BIP 157 i BIP 158 definišu protokole i filtere koji omogućavaju da klijent preuzima filtere i lokalno odlučuje koje blokove treba detaljnije proveriti.[6]

Hosted API ili procesor plaćanja

Treća strana može ponuditi webhookove, generisanje invoice-a, konverziju, custody i administrativni interfejs.

To ubrzava razvoj, ali uvodi:

poverenje u podatke i dostupnost provajdera,
custody rizik ako provajder drži ključeve,
identifikaciju korisnika i operativna ograničenja,
naknade i potencijalni vendor lock-in.

Nijedan pristup nije univerzalno najbolji. Čest kompromis je korišćenje sopstvenog čvora za verifikaciju i posebnog servisa za funkcije koje proizvod ne želi sam da održava.

Minimalan lokalni eksperiment sa Bitcoin Core

Za razvoj ne treba koristiti pravi BTC. Bitcoin Core ima regtest, privatni režim u kojem lokalno generišete blokove kada su vam potrebni.

Sledeći primer pretpostavlja instalirane komande bitcoind i bitcoin-cli:

bitcoind -regtest -daemon

bitcoin-cli -regtest createwallet payer
bitcoin-cli -regtest createwallet merchant

MINER_ADDRESS=$(
    bitcoin-cli -regtest -rpcwallet=payer getnewaddress
)

bitcoin-cli -regtest generatetoaddress 101 "$MINER_ADDRESS"

PAYMENT_ADDRESS=$(
    bitcoin-cli -regtest -rpcwallet=merchant getnewaddress
)

TXID=$(
    bitcoin-cli -regtest -rpcwallet=payer \
        sendtoaddress "$PAYMENT_ADDRESS" 0.001
)

bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generatetoaddress 1 "$MINER_ADDRESS"

bitcoin-cli -regtest -rpcwallet=merchant gettransaction "$TXID"

Prvih 101 blokova nisu tu radi simulacije realnog protoka vremena. Potrebni su da bi coinbase izlaz postao potrošiv nakon propisane zrelosti.

Ovaj eksperiment pokazuje nekoliko osnovnih stvari:

adrese generiše konkretan wallet,
transakcija se prvo pojavljuje kao nepotvrđena,
rudar, u ovom slučaju lokalna komanda, uključuje je u blok,
wallet nakon novog bloka vidi potvrdu.

regtest nije simulacija ekonomskih uslova glavne mreže. Nema realno tržište naknada, distribuirane peerove ni konkurentne rudare. Namenjen je determinističkim integracionim testovima.

Za javno testiranje postoje test mreže, ali testni novčići nemaju namenu produkcionog novca.

JSON-RPC nije javni web API

Bitcoin Core izlaže JSON-RPC namenjen pouzdanim klijentima u kontrolisanom okruženju. Ne treba ga direktno objaviti na internetu niti proslediti korisničkom frontendu.

Tipična arhitektura izgleda ovako:

flowchart LR
    U[Korisnički klijent] --> A[Aplikativni API]
    A --> D[(Baza invoice-a)]
    A --> Q[Red poslova]
    Q --> W[Bitcoin worker]
    W --> N[Bitcoin Core čvor]
    N --> P[Bitcoin P2P mreža]
    W --> D
    D --> A

Aplikativni sloj treba da:

autentifikuje poslovne zahteve,
mapira invoice na očekivanu skriptu ili adresu,
čuva iznose kao integer satoshije,
prati potvrde i reorganizacije,
primenjuje politiku isporuke,
ograniči RPC privilegije,
spreči da proizvoljni RPC poziv stigne do čvora.

Bitcoin Core podržava RPC metode za blockchain, mrežu, mempool, novčanike, transakcije i procenu naknada.[7] Koje metode treba koristiti zavisi od toga da li aplikacija čuva privatne ključeve u Core wallet-u ili čvor koristi samo kao validator i izvor podataka.

Realan use-case: backend za Bitcoin invoice

Zamislimo SaaS proizvod koji prodaje godišnju licencu i želi da prihvati on-chain Bitcoin bez automatske konverzije unutar samog backenda.

Dobar workflow bi mogao da izgleda ovako:

Backend kreira invoice sa internim ID-em.
Za invoice rezerviše novu adresu iz kontrolisanog wallet descriptora.
Zaključava cenu na ograničeno vreme prema izabranom izvoru kursa.
Iznos čuva kao integer broj satoshija.
Prati transakcije koje kreiraju izlaz ka očekivanoj skripti.
Beleži nepotvrđenu uplatu, ali još ne aktivira nepovratnu isporuku.
Nakon definisanog broja potvrda menja invoice u paid.
Ako dođe do reorganizacije, ponovo izračunava status.
Posebno obrađuje premalu, preveliku, zakasnelu i višestruku uplatu.

Model stanja može biti jednostavan:

pending
seen_unconfirmed
confirming
paid
expired
underpaid
overpaid
conflicted
refunded

Greška je modelovati status samo kao boolean paid. Distribuirani sistem ima prelazna stanja, a blockchain reorganizacije znače da čak ni prelaz iz nepotvrđenog u potvrđeno nije nužno monotono jednosmeran.

Jedinstvena adresa po invoice-u

Ponovna upotreba iste adrese olakšava implementaciju, ali otežava povezivanje uplata sa narudžbinama i ozbiljno narušava privatnost.

Jedinstvena adresa po invoice-u omogućava direktno mapiranje izlaza na poslovni objekat. Ipak, treba izbegavati generisanje adresa bez pouzdane evidencije derivacionog stanja.

Watch-only wallet može da prati uplate bez posedovanja privatnih ključeva. Potpisivanje se zatim može obavljati na odvojenom uređaju ili sistemu.

Ne tražite transakciju samo po iznosu

Mapiranje uplate preko „tačno 0,001234 BTC“ krhko je zato što:

dva korisnika mogu poslati isti iznos,
korisnik može poslati pogrešan iznos,
uplata može stići posle isteka invoice-a,
jedna transakcija može platiti više izlaza,
korisnik može napraviti više delimičnih uplata.

Primarni identitet očekivane uplate treba vezati za skriptu ili namensku adresu, a iznos i vreme koristiti kao dodatna poslovna pravila.

Webhook nije izvor istine

Ako koristite webhook, tretirajte ga kao signal da proverite stanje, ne kao konačni autoritet.

Webhook može biti:

poslat više puta,
isporučen van redosleda,
zakasneo,
izgubljen,
lažiran ako autentifikacija nije dobra.

Handler treba da bude idempotentan. Stvarno stanje treba ponovo izračunati iz pouzdanog izvora podataka i sačuvati zajedno sa visinom bloka i hashom bloka koji je poslužio za odluku.

PSBT i odvajanje potpisivanja

Partially Signed Bitcoin Transaction, odnosno PSBT, standardizuje razmenu nepotpisanih ili delimično potpisanih transakcija između različitih komponenti.[8]

Tipičan tok izgleda ovako:

Online sistem bira UTXO-e i konstruiše predlog transakcije.
PSBT se prenosi uređaju ili servisu za potpisivanje.
Potpisnik proverava destinacije, iznose i naknadu.
Jedan ili više potpisnika dodaju potpise.
Finalizovana transakcija vraća se online sistemu.
Online sistem je objavljuje mreži.

PSBT je koristan kada:

privatni ključevi ne smeju biti na web serveru,
postoji hardware wallet,
potreban je multisig,
različiti sistemi obavljaju coin selection, potpisivanje i broadcast.

Format rešava interoperabilnost poruka. Ne rešava automatski autorizaciju. Potpisnik i dalje mora da zna da li je predložena destinacija legitimna i da li aplikacija pokušava da plati neočekivano visoku naknadu.

Custodial i non-custodial nisu marketinške etikete

Ako platforma može samostalno da potpiše povlačenje korisnikovih sredstava, ona ima custody bez obzira na terminologiju interfejsa.

Model	Ko kontroliše ključeve	Glavna prednost	Glavni rizik
Custodial	Servis	Jednostavan oporavak i UX	Kompromitovanje ili blokada servisa
Self-custody	Korisnik	Direktna kontrola sredstava	Gubitak ključa ili loš backup
Multisig	Više ključeva	Podela ovlašćenja	Složeniji oporavak i koordinacija
Watch-only	Niko u online sistemu	Bezbedno praćenje uplata	Ne može samostalno da potpisuje

Self-custody nije automatski bezbedniji. Loše napravljen self-custody wallet može biti opasniji od kvalitetno održavanog custodial servisa. Razlika je pre svega u tome ko može da napravi validan potpis i ko snosi posledice gubitka ključa.

Lightning kao sloj za česta i mala plaćanja

On-chain Bitcoin daje globalno poravnanje, ali nije idealan za svaki checkout. Blokovi dolaze u prosečnim intervalima, prostor je ograničen, a naknade se menjaju.

Lightning Network koristi kanale plaćanja čije se otvaranje i zatvaranje oslanja na Bitcoin transakcije. Unutar mreže se zatim mogu izvršavati česta plaćanja bez upisivanja svakog pojedinačnog plaćanja u blockchain.

Prednosti mogu biti:

brzo korisničko iskustvo,
niži trošak malih plaćanja,
bolja pogodnost za mikrotransakcije.

Trade-off uključuje:

upravljanje likvidnošću kanala,
dostupnost čvora ili poverenje u provajdera,
složenije rutiranje,
inbound i outbound kapacitet,
backup i monitoring stanja.

Lightning nije zamena za razumevanje osnovnog Bitcoin modela. On koristi Bitcoin transakcije i vremenska zaključavanja kao sigurnosni sloj.

Bezbednosni problemi koje aplikacije često potcene

Ključevi u application database-u

Šifrovanje privatnog ključa u istoj bazi, dok ključ za dešifrovanje stoji u environment varijabli iste aplikacije, štiti od nekih curenja backupa. Ne štiti od napadača koji izvršava kod u procesu aplikacije.

Za veće iznose razmotrite:

odvojeni signer,
hardware security module,
hardware wallet,
multisig sa organizaciono odvojenim ključevima,
ograničene hot-wallet iznose,
manuelnu kontrolu velikih povlačenja.

Slepo potpisivanje

Signer koji samo primi serijalizovanu transakciju i potpiše je nije prava bezbednosna granica. Mora primenjivati politiku:

dozvoljene destinacije,
maksimalan iznos,
maksimalan feerate,
očekivane izlaze za kusur,
dnevne limite,
potrebna dodatna odobrenja.

Backup bez testa oporavka

Backup nije pouzdan dok oporavak nije testiran.

Test mora potvrditi da su sačuvani:

seed ili ključevi,
descriptor podaci,
derivacione putanje,
potrebne passphrase vrednosti,
multisig konfiguracija,
procedure i ovlašćena lica.

Adresa promenjena u clipboardu

Malver može zameniti Bitcoin adresu nakon kopiranja. Interfejs treba da prikaže celu ili dovoljno karakterističnu adresu pre potvrde. Hardware signer treba da prikaže destinaciju na nezavisnom ekranu.

Logovanje tajnih podataka

Request body, crash dump, analytics događaj ili tracing sistem mogu nenamerno sačuvati seed, privatni ključ, PSBT ili autentifikacione podatke za RPC.

Osetljivi objekti moraju biti eksplicitno isključeni iz logova. Generičko „loguj ceo request u debug režimu“ nije prihvatljivo za wallet servis.

Privatnost nije podrazumevana

Bitcoin blockchain je javan. Adrese nisu direktno imena, ali transakcioni graf omogućava povezivanje aktivnosti.

Analiza može koristiti:

ponovnu upotrebu adresa,
zajedničko trošenje više ulaza,
prepoznatljive izlaze za kusur,
vremensko povezivanje,
podatke koje otkrivaju berze i merchant sistemi,
mrežne metapodatke.

Zato pseudonimnost nije isto što i anonimnost.

Aplikacija koja generiše posebnu adresu za svakog korisnika možda tehnički pojednostavljuje knjigovodstvo, ali istovremeno pravi dugoročnu mapu identiteta i aktivnosti. Te podatke treba tretirati kao osetljive.

Sopstveni čvor poboljšava privatnost upita. Ako za svaku korisničku adresu pitate javni explorer, provajder može povezati IP adresu servera, vreme upita i skup adresa koje pripadaju istoj aplikaciji.

Najvažniji trade-offovi

Odluka	Dobitak	Cena
Sopstveni full node	Nezavisna validacija i privatnost	Infrastruktura i održavanje
Hosted procesor	Brža integracija	Poverenje, naknade i zavisnost
On-chain naplata	Jednostavan model poravnanja	Čekanje i promenljive naknade
Lightning	Brza mala plaćanja	Likvidnost i operativna složenost
Self-custody	Kontrola ključeva	Odgovornost za backup i sigurnost
Custodial wallet	Jednostavniji UX	Rizik druge strane
Zero-confirmation isporuka	Brži checkout	Rizik konflikta ili zamene
Više potvrda	Veća sigurnost poravnanja	Sporija isporuka
Jedna adresa po invoice-u	Lakše knjiženje i bolja privatnost	Upravljanje derivacijom
Konsolidacija UTXO-a	Jeftinije buduće trošenje	Trenutna naknada i gubitak privatnosti

Kada Bitcoin ima smisla u proizvodu

Bitcoin je razuman izbor kada proizvodu treba jedna ili više sledećih osobina:

globalni prenos bez obaveznog kartičnog procesora,
javno proverljivo poravnanje,
rad sa korisnicima koji već poseduju BTC,
programabilna politika potpisivanja,
mogućnost sopstvene validacije,
dugoročno držanje sredstava bez zavisnosti od poslovne baze jednog provajdera.

Manje je pogodan kada proizvod zahteva:

trenutnu i nepovratnu finalnost bez dodatnog sloja,
stabilnu obračunsku vrednost u fiat valuti,
automatski povraćaj sredstava nalik chargeback-u,
potpunu privatnost transakcija,
jednostavan recovery za korisnika koji izgubi sve ključeve,
zanemarljiv operativni teret.

Dobra integracija ne pokušava da sakrije ove razlike. Ona poslovni workflow projektuje oko njih.

Šta developer zapravo može da nauči

Najvredniji deo eksperimentisanja sa Bitcoinom nije slanje simbolične količine između dva wallet-a. Vrednost je u posmatranju sistema pod greškama i prelaznim stanjima.

Koristan testni plan uključuje:

uplatu bez potvrde,
uplatu sa jednom potvrdom,
više delimičnih uplata,
preveliku uplatu,
uplatu posle isteka invoice-a,
zamenu nepotvrđene transakcije,
blok koji više nije deo aktivnog lanca,
restart čvora dok worker obrađuje događaj,
dupliran webhook ili događaj,
privremeno nedostupan RPC,
wallet koji nema privatne ključeve,
povlačenje sa velikim brojem malih UTXO-a.

Takvi testovi brzo otkrivaju da blockchain integracija nije samo poziv funkcije send(). To je obrada događaja iz distribuiranog sistema u kojem potvrde stižu vremenom, neki događaji se ponavljaju, a ranije opaženo stanje može kratkotrajno biti promenjeno.

Zaključak

Bitcoin radi tako što veliki broj nezavisnih čvorova proverava isti skup pravila, dok proof of work daje praktičan mehanizam za izbor redosleda validnih transakcija bez centralnog koordinatora.

Njegov osnovni podatkovni model nije stanje računa, već skup nepotrošenih izlaza. Novčanik nije mesto na kojem se bitcoin fizički nalazi, već sistem za praćenje izlaza i upravljanje ključevima. Rudari ne određuju proizvoljno pravila, potvrda nije apsolutna finalnost, a naknada zavisi od prostora koji transakcija zauzima, ne od njene monetarne vrednosti.

Za developera koji želi da ga integriše, najvažnija odluka nije izbor biblioteke. Važnije je odrediti model poverenja: ko validira blockchain, ko drži ključeve, koliko potvrda je potrebno, kako se obrađuje reorganizacija i šta se dešava kada infrastruktura zakaže.

Kada su te odluke eksplicitne, Bitcoin prestaje da izgleda kao magična crna kutija. Postaje ono što jeste: relativno mali skup strogo definisanih pravila, okružen veoma složenim ekonomskim i distribuiranim sistemom.

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: Dora Milen

USDT i USDC u praksi: stablecoin izbor za developere

Šta je USDT

Šta je USDC

Stablecoin nije isto što i dolar na bankovnom računu

Zašto bi developer koristio stablecoin

Kako se USDT i USDC integrišu

Direktna on-chain integracija

Custodial ili wallet infrastruktura

Integracija sa izdavačem ili on-ramp providerom

Nemoj identifikovati token samo simbolom

USDT ima važan ERC-20 detalj

Deposit workflow je više od slušanja Transfer događaja

Iznose čuvaj kao cele brojeve

Cross-chain nije običan transfer

Koliko košta integracija

Blockchain naknade

Infrastruktura

Konverzija na sekundarnom tržištu

Direktan rad sa Tetherom

Direktan rad sa Circleom

USDT vs USDC: ključne razlike

Prednosti i mane USDT-a

Prednosti

Mane

Prednosti i mane USDC-a

Prednosti

Mane

Kako izabrati između USDT-a i USDC-a

Izaberi prema primaocu

Izaberi mrežu pre biblioteke

Proveri izlaz pre ulaza

Ne moraš podržati oba

Produkciona checklista

Zaključak

Sponzorstvo

Izvori

Polygon POL iz ugla developera: EVM, gas i finalnost

POL nije samo novi simbol za MATIC

Kako Polygon Chain zapravo radi

Kada Polygon ima smisla

Realan use-case: program lojalnosti više partnera

POL ne mora biti vidljiv korisniku

Integracija je standardni EVM workflow

Receipt nije isto što i finalnost

Koliko košta transakcija

Kako organizovati backend

Transaction service

Nonce manager

Event indexer

Reconciliation worker

Most nije običan transfer

Glavni trade-offi

Dobijaš EVM kompatibilnost

Dobijaš bržu finalnost

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

Korisnicima je potreban POL ili sponzor

Bezbednosni model nije Ethereum L1

Javni RPC nije produkcioni SLA

Polygon Chain, CDK i zkEVM nisu ista odluka

Praktična odluka

Sponzorstvo

Izvori

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

Avalanche nije jedan blockchain

Šta developer dobija na C-Chainu

Kada shared EVM prestaje da bude dovoljan

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

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

1. Izolujte chain-specific delove aplikacije

2. Eksplicitno postavite Cancun EVM target

3. Deployujte na Fuji

4. Testirajte ponašanje sistema, ne samo ugovore

5. Napravite lokalni L1 tek kada imate konkretan zahtev

Koliko košta Avalanche

Trošak C-Chain aplikacije

Trošak sopstvenog L1

Helicon menja detalje fee i execution modela

Interoperabilnost nije isto što i jedan shared state

Trade-off koji marketing obično preskoči

Deposit workflow je više od slušanja `Transfer` događaja

TRC-20 nije samo poziv funkcije `transfer`

Šta zapravo radi `fee_limit`