Dora Milen

Posted on Sep 18

Bitcoin iz ugla developera: protokol, čvorovi i kod

#blockchain #cryptocurrency #web3 #bitcoin

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.