Ripple, XRP i XRPL: detaljna arhitektura za developere

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:

1. Server prima kandidat transakcije.
2. Validatori predlažu skup transakcija za narednu verziju ledgera.
3. Predlozi se porede u više rundi.
4. Validatori prilagođavaju predlog prema transakcijama koje imaju dovoljan nivo podrške.
5. Transakcije se izvršavaju determinističkim redosledom.
6. Validatori objavljuju validacije rezultujućeg ledgera.
7. 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

1. Korisnik dobija adresu i destination tag.
2. Platforma prati transakcije koje utiču na operational nalog.
3. Za svaku pristiglu transakciju proverava da li je rezultat validiran.
4. Proverava da je meta.TransactionResult jednak tesSUCCESS.
5. Proverava Destination i DestinationTag.
6. Stvarni primljeni iznos čita iz delivered_amount.
7. Proverava currency i issuer, ne samo ticker.
8. Upisuje ledger index i transaction hash.
9. 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

1. Korisnik šalje destination adresu, tag i traženi iznos.
2. Backend validira format adrese i proverava poslovna ograničenja.
3. Interna baza rezerviše iznos za payout.
4. Signing servis konstruiše transakciju.
5. autofill pribavlja Sequence, Fee i LastLedgerSequence.
6. Transakcija se potpisuje u izolovanom signing okruženju.
7. Potpisani blob i hash čuvaju se pre slanja.
8. Blob se šalje jednom ili više trusted servera.
9. Sistem čeka validirani rezultat.
10. 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.

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

1. XRP Ledger dokumentacija: What Is XRP?
2. Ripple: Frequently Asked Questions
3. XRP Ledger dokumentacija: Consensus Protocol
4. XRP Ledger dokumentacija: Accounts
5. XRP Ledger dokumentacija: Source and Destination Tags
6. XRP Ledger dokumentacija: Transaction Cost
7. XRP Ledger dokumentacija: Reserves
8. XRP Ledger dokumentacija: Paths
9. XRP Ledger dokumentacija: Reliable Transaction Submission
10. XRP Ledger dokumentacija: Payment Transaction
11. XRP Ledger dokumentacija: Robustly Monitoring for Payments
12. XRP Ledger dokumentacija: Trust Line Tokens
13. XRP Ledger dokumentacija: Multi-Purpose Tokens
14. XRP Ledger dokumentacija: Decentralized Exchange
15. XRP Ledger dokumentacija: Automated Market Makers
16. XRP Ledger dokumentacija: Public Servers
17. XRP Ledger dokumentacija: HTTP and WebSocket APIs
18. XRP Ledger dokumentacija: The Clio Server
19. XRP Ledger dokumentacija: Cryptographic Keys
20. XRP Ledger dokumentacija: Amendments
21. XRPL EVM Sidechain dokumentacija
22. Volet Srbija