Minsan tinutukoy ang
Bitcoin bilang
nai-program na pera. Dahil sa digital na katangian, pinapayagan ang mga user ng isang mahusay na antas ng kakayahang umangkop pagdating sa pagtatakda ng mga kundisyon para sa kung paano puwedeng gastusin ang mga pondo.
Pinag-uusapan natin ang
mga wallet at
mga coin kapag tinatalakay ang Bitcoin. Ngunit puwede rin nating isipin ang mga wallet bilang mga susi, coin bilang tseke, at ang
blockchain bilang sunud-sunod na mga safe na naka-lock. Ang bawat safe ay may manipis na puwang dito, tulad ng sinumang puwedeng mag-deposito ng mga tseke o tumingin upang makita kung gaano kahalaga ang mga ligtas na humahawak. Gayunpaman, ang key holder lang ang makaka-access sa loob.
Kapag nais ng isang key holder na magbigay ng pera sa iba, ina-unlock nila ang kanilang kahon. Gumagawa sila ng isang bagong tseke na tumutukoy sa mas matanda (na kung saan ay nawasak) at ma-lock ito sa isang kahon na puwedeng buksan ng tatanggap. Upang gastusin iyon, inuulit ng bagong tatanggap ang proseso.
Sa artikulong ito, titingnan namin nang mas malapit ang Script, ang programming language na binibigyang kahulugan ng
mga node sa Bitcoin network. Ang script ay kung ano ang namamahala sa mekanismo ng pagla-lock/pag-unlock na nabanggit para sa mga safe.
Ang pagpapatakbo ng aming pagkakatulad mula sa itaas, puwede mong sabihin na mayroong dalawang bahagi sa bawat transaksyon – isang key (upang ma-unlock ang iyong kahon) at isang lock. Ginagamit mo ang iyong key upang buksan ang kahon na naglalaman ng tseke na nais mong ipadala, at pagkatapos ay magdagdag ka ng bago sa isang bagong kahon na may ibang lock. Upang gumastos mula sa bagong kahon, kailangan mo ng isa pang key.
Sapat na simple. Puwede ka ring makakuha ng kaunting pagkakaiba-iba sa mga uri ng mga kandado sa system. Marahil ang ilang mga safe ay nangangailangan na magbigay ka ng
maraming mga key, at marahil kailangan ka ng iba upang patunayan na alam mo ang isang lihim. Mayroong isang bungkos ng mga kundisyon na puwedeng itakda ng mga tao.
Ang aming key ay ang tinatawag naming scriptSig. Ang lock ay ang aming scriptPubKey. Kung titingnan namin ang mga sangkap na iyon nang medyo mas detalyado, mahahanap namin na talagang binubuo ang mga ito ng mga piraso ng data at mga block ng code. Kapag pinagsama, lumilikha sila ng isang maliit na programa.
Kapag gumawa ka ng isang transaksyon, isinasapubliko mo ang network sa kombinasyon na iyon. Ang bawat node na tumatanggap nito ay susuriin ang programa, na nagsasabi rito kung wasto ang transaksyon. Kung hindi, itatapon lang ito, at hindi mo magagastos ang naka-lock na mga pondo.
Ang mga tseke (coin) na hawak mo ay tinatawag na
hindi nagamit na mga output ng transaksyon (UTXOs). Ang mga pondo ay puwedeng magamit ng sinuman na puwedeng magbigay ng key na umaangkop sa lock. Partikular, ang key ay ang scriptSig at ang lock ay ang scriptPubKey.
Kung ang mga UTXO ay nasa iyong wallet, marahil ay magkakaroon sila ng kundisyon na nagsasabing
ang tao lang na puwedeng magpatunay ng pagmamay-ari ng pampublikong key na ito ang puwedeng mag-unlock ng mga pondong ito. Upang ma-unlock ito, magkapagbigay ka ng isang scriptSig na may kasamang isang
digital signature, gamit ang
private key na nagma-map sa pampublikong key na tinukoy sa scriptPubKey. Magiging mas malinaw ito sa ilang sandali.-.
Ang script ay ang kilala bilang isang wika na batay sa stack. Ang ibig sabihin lang nito ay, kapag nabasa natin ang isang hanay ng mga tagubilin, inilalagay namin ang mga ito sa puwedeng maiisip bilang isang patayong haligi. Ang listahan ng A, B, C, halimbawa, ay magreresulta sa isang stack na may A sa ibaba, at C sa itaas. Kapag sinabi sa amin ng mga tagubilin na gumawa ng isang bagay, nagpapatakbo kami sa isa o higit pang mga elemento na nagsisimula sa tuktok ng stack.
Ang mga elemento ng A, B, at C ay idinagdag at “nag-pop” mula sa stack.
Puwede nating makilala ang data (mga bagay tulad ng
mga signature,
mga hash, at mga pampublikong key) at mga tagubilin (o
opcode). Ang mga tagubilin ay nag-aalis ng data at may ginagawa dito. Narito ang isang napakasimpleng halimbawa ng kung ano ang puwedeng hitsura ng isang script:
<xyz> <md5 hasher> <d16fb36f0911f878998c136191af705e> <check if equal>
Sa pula, mayroon kaming data, at sa asul, mayroon kaming mga opcode. Nabasa namin mula kaliwa hanggang kanan, kaya inilagay muna namin ang string na <xyz> stack. Ang susunod ay ang <md5 hasher> opcode. Ang isang ito ay hindi nag-exist sa Bitcoin, ngunit sabihin nating tinatanggal nito ang nangungunang elemento ng stack (<xyz>) at ini-hash ito gamit ang MD5 algorithm. Pagkatapos, ang output ay maidaragdag pabalik sa stack. Ang output dito ay nangyayari na maging d16fb36f0911f878998c136191af705e.
Anong pagkakataon! Ang aming susunod na elemento na idaragdag ay <d16fb36f0911f878998c136191af705e>, kaya ngayon ang aming stack ay may dalawang magkatulad na mga elemento. Panghuli, <check if equal> nagpa-pop ng dalawang elemento sa itaas at sinusuri kung pantay ang mga ito. Kung ang mga ito, nagdaragdag ito ng <1> sa stack. Kung hindi, nagdaragdag ito ng <0>.
Natapos na namin ang aming listahan ng mga tagubilin. Puwedeng bumagsak ang aming script sa dalawang paraan - kung ang natitirang elemento ay zero, o kung ang isa sa mga operator ang nagdulot nito na mabigo kapag hindi natugunan ang ilang mga kundisyon. Wala kaming anumang mga naturang operator sa halimbawang ito, at nagtapos kami sa isang hindi-zero na elemento (<1>), kaya wasto ang aming script. Totoo ang mga patakarang ito para sa mga tunay na transaksyon sa Bitcoin.
Isang gawa-gawa lang na programa iyon. Tingnan natin ang ilang mga aktwal na ngayon.
Ang Pay-to-Pubkey (P2PK) ay hindi kapani-paniwalang prangka. Nagsasangkot ito ng pag-lock ng mga pondo sa isang partikular na public key. Kung nais mong makatanggap ng mga pondo sa ganitong paraan, bibigyan mo ang nagpadala ng iyong public key, taliwas sa isang Bitcoin address.
Ang
pinakaunang transaksyon sa pagitan ni
Satoshi Nakamoto at Hal Finney noong 2009 ay isang P2PK. Ang istraktura ay mabigat na ginamit sa mga unang araw ng Bitcoin, ngunit sa panahong ito, ang Pay-to-Pubkey-Hash (P2PKH) ay higit na pinalitan ito.
Ang locking script para sa isang transaksyon sa P2PK ay sumusunod sa format ng <public key> OP_CHECKSIG. Sapat na simple. Puwedeng nahulaan mo na ang OP_CHECKSIG ay sumusuri para sa isang signature laban sa ibinigay na public key. Tulad ng naturan, ang aming scriptSig ay magiging simple <signature>. Tandaan, ang scriptSig ay ang key sa lock.
Hindi ito nagiging mas simple kaysa dito. Ang isang signature ay naidagdag sa stack, na sinusundan ng isang public key. Ang OP_CHECKSIG ay nagpa-pop sa kanila pareho at na-verify ang signature laban sa public key. Kung tumutugma sila, nagdaragdag ito ng <1> isang stack. Kung hindi man, nagdaragdag ito ng isang <0>.
Para sa mga kadahilanang isasaad namin sa susunod na seksyon, hindi na talaga ginagamit ang P2PK.
Ang Pay-to-Pubkey-Hash (P2PKH) na ngayon ang pinakakaraniwang uri ng transaksyon. Maliban kung aalis ka sa iyong paraan upang mag-download ng archaic software, malamang na gawin ito ng iyong wallet bilang default.
Ang scriptPubKey sa P2PKH ay ang sumusunod
OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG
Bago namin ipakilala ang scriptSig, paghiwalayin natin kung ano ang gagawin ng mga bagong opcode
OP_DUP
Ang OP_DUP ay nagpa-pop ng unang elemento, at dinu-doble ito . Pagkatapos, nagdaragdag ito ng parehong pabalik sa stack. Karaniwan, ginagawa ito upang makagawa kami ng isang operasyon sa duplicate nang hindi nakakaapekto sa orihinal.
OP_HASH160
Ito ang nagpa-pop sa unang elemento at na-hash ito nang dalawang beses. Ang unang pag-ikot ay mag-hash gamit ang SHA-256 algorithm. Ang output ng SHA-256 pagkatapos ay na-hash gamit ang RIPEMD-160 algorithm. Ang nagresultang output ay idinagdag pabalik sa stack.
OP_EQUALVERIFY
Pinagsasama ng OP_EQUALVERIFY ang dalawang iba pang mga operator – OP_EQUAL at OP_VERIFY. Ang OP_EQUAL ay pop ng dalawang elemento at susuriin kung magkatulad ang mga ito. Kung ang mga ito, nagdaragdag ito ng 1 sa stack. Kung hindi, nagdaragdag ito ng 0. OP_VERIFY na pops ang nangungunang elemento at susuriin kung ito ay Totoo (ibig sabihin, hindi-zero). Kung hindi, nabigo ang transaksyon. Pinagsama, ang OP_EQUALVERIFY ay nagiging sanhi ng pagkabigo ng transaksyon kung ang dalawang nangungunang elemento ay hindi tumutugma.
Sa oras na ito, ganito ang hitsura ng scriptSig
<signature> <public key>
Kailangan mong magbigay ng isang signature at ang kaukulang public key upang ma-unlock ang mga output ng P2PKH.
Puwede mong makita kung ano ang nangyayari sa GIF sa itaas. Hindi ito masyadong naiiba mula sa isang script na P2PK. Nagdaragdag lang kami ng isang karagdagang hakbang upang suriin na ang public key ay tumutugma sa hash sa script.
Mayroong isang bagay na dapat tandaan, gayunpaman. Sa isang P2PKH locking script, ang public key ay hindi nakikita – puwede lang namin makita ang hash nito. Kung pupunta kami sa
explorer sa blockchain at tingnan ang isang output na P2PKH na hindi nagastos, hindi namin matukoy ang public key. Ipinahayag lang ito kapag nagpasya ang tatanggap na ilipat ang mga pondo.
Ito ay may pares ng mga benepisyo. Ang una ay ang public key hash ay mas madaling dumaan kaysa sa isang buong public key. Inilunsad ito ni Satoshi noong 2009 para sa mismong kadahilanang ito. Ang public key hash ay ang alam natin bilang Bitcoin address ngayon.
Ang pangalawang benepisyo ay ang mga public key hash na puwedeng magbigay ng isang karagdagang layer ng seguridad laban sa
quantum computing. Dahil ang aming public key ay hindi nalalaman hanggang sa gumastos kami ng mga pondo, mas mahirap para sa iba na makalkula ang private key. Kailangan nilang baligtarin ang dalawang pag-ikot ng pag-hash (RIPEMD-160 at SHA-256) upang makuha ito.
Ang Pay-to-Script-Hash (P2SH) ay isang nakawiwiling pag-unlad para sa
Bitcoin. Pinapayagan nito ang nagpadala na ma-lock ang mga pondo sa hash ng isang script – hindi nila kailangang malaman kung ano talaga ang ginagawa ng script. Kunin ang sumusunod na SHA-256 hash:
e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1
Hindi mo kailangang malaman ang input ng hash upang ma-lock ang mga pondo dito. Gayunpaman, ang nagastos ay kailangang magbigay ng script na ginamit upang i-hash ito at kailangang masiyahan ang mga kondisyon ng script na iyon.
Ang hash sa itaas ay nilikha mula sa sumusunod na script:
<multiply by 2> <4> <check if equal>
Kung nais mong gugulin ang mga coin na nakatali sa scriptPubKey na iyon, hindi mo lang ibinibigay ang mga utos na iyon. Kailangan mo rin ng isang scriptSig na ginagawang suriin ang nakumpletong script sa True. Sa halimbawang ito, iyan ay isang elemento na na-multiply ng 2 <multiply by 2> upang magbigay ng isang resulta <4>. Siyempre, nangangahulugan iyon na ang aming scriptSig ay lang <2>.
Sa totoong buhay, ang scriptPubKey para sa isang output na P2SH ay:
OP_HASH160 <redeemScript hash> OP_EQUAL
Walang mga bagong operator dito. Ngunit, mayroon kaming <redeemScript hash> bilang isang bagong elemento. Tulad ng ipinahihiwatig ng pangalan, ito ay isang hash ng script na kailangan naming ibigay upang makuha ang mga pondo (tinatawag na ransomScript). Magbabago ang scriptSig depende sa kung ano ang nasa ransomScript. Gayunpaman, sa pangkalahatan, mahahanap mo na ito ay ilang kumbinasyon ng mga signature at ang nakakabit na mga public key, na sinusundan ng (ipinag-uutos) na ransomScript:
<signature> <public key> <redeemScript>
Ang aming pagsusuri ay naiiba nang kaunti sa pagpapatupad ng stack na nakita namin sa ngayon. Nangyayari ito sa dalawang bahagi. Ang una ay simpleng sumusuri na naibigay mo ang tamang hash.
Mapapansin mong hindi kami gumagawa ng anumang bagay sa mga elemento bago ang ransomScript. Hindi sila ginagamit sa puntong ito. Narating namin ang pagtatapos ng mini-program na ito, at ang nangungunang elemento ay hindi zero. Nangangahulugan iyon na wasto ito.
Hindi pa tayo tapos. Kinikilala ng mga network
node ang istrakturang ito bilang P2SH, kaya talagang nakuha nila ang mga elemento ng scriptSig na naghihintay sa isa pang stack. Doon gagamitin ang signature at public key.
Sa ngayon, itinuring namin ang ransomScript bilang isang elemento. Ngunit ngayon, bibigyan ito ng kahulugan bilang mga tagubilin, na puwedeng maging anupaman. Gawin nating halimbawa ang isang P2PKH locking script, kung saan dapat naming ibigay ang <signature> at <public key> na tumutugma sa <public key hash> sa loob ng <redeemScript>.
Sa sandaling napalawak ang iyong ransomScript, makikita mo na mayroon kaming isang sitwasyon na eksaktong hitsura ng isang regular na P2PKH na transaksyon. Mula doon, patakbuhin mo lang ito tulad ng iyong ginagawa sa isang normal.
Ipinakita namin ang tinatawag na isang script na P2SH (P2PKH) dito, ngunit malamang na hindi ka makahanap ng isa sa mga nasa ligaw. Walang pumipigil sa iyo sa paggawa ng isa, ngunit nagbibigay ito sa iyo ng walang idinagdag na mga benepisyo at nagtatapos sa pagkuha ng mas maraming blangko sa isang block (at, samakatuwid, mas malaki ang gastos).
Sa pangkalahatan ay madaling gamitin ang P2SH para sa mga bagay tulad ng
multisignature o mga transaksyong katugma sa
SegWit. Ang mga transaksyon sa multisig ay puwedeng napakalaki ng laki dahil puwedeng mangailangan sila ng maraming mga key. Bago ang pagpapatupad ng Pay-to-Script-Hash, kailangang ilista ng isang nagpadala ang lahat ng posibleng mga public key sa kanilang script sa pag-lock.
Ngunit sa P2SH, hindi mahalaga kung gaano kumplikado ang mga kondisyon sa paggastos. Ang hash ng ransomScript ay palaging isang nakapirming laki. Ang gastos ay ipinapasa sa mga (mga) gumagamit na nais na ma-unlock ang script ng pagla-lock.
Ang pagiging tugma ng SegWit ay isa pang kaso kung saan madaling gamitin ang P2SH (makukuha namin ang mga detalye kung paano naiiba ang istraktura ng transaksyon sa susunod na seksyon). Ang SegWit ay isang soft fork na nagresulta sa isang pagbabago sa mga format ng block/transaksyon. Dahil ito ay isang pag-upgrade sa pag-opt-in, hindi lahat ng software ng wallet ay kinikilala ang mga pagbabago.
Hindi mahalaga kung ibalot ng mga kliyente ang hash ng SegWit script sa P2SH. Tulad ng lahat ng mga transaksyon ng ganitong uri, hindi nila kailangang malaman kung ano ang magiging unlock ng ransomScript.
Upang maunawaan ang format ng transaksyon sa SegWit, kailangan mo lang malaman na wala na kaming scriptSig at scriptPubKey. Ngayon, mayroon din kaming bagong larangan na tinatawag na witness. Ang data na dati naming itinatago sa scriptSig ay inililipat sa witness, kaya't walang laman ang scriptSig.
Kung may nakasaluha kang mga address na nagsisimula sa ‘bc1’, iyon ang tinatawag naming SegWit-native (taliwas sa SegWit-compatible lang, na nagsisimula sa ‘3’ dahil ang mga ito ay P2SH address).
Pay-to-Witness-Pubkey-Hash (P2WPKH)
Ang Pay-to-Witness-Pubkey-Hash (P2WPKH) ay ang bersyon ng SegWit na P2PKH. Ganito ang aming witness:
<signature> <public key>
Mapapansin mo na ito ay kapareho ng scriptSig mula sa P2PKH. Dito, walang laman ang scriptSig. Samantala, ang scriptPubKey ay kahawig ng mga sumusunod
<OP_0> <public key hash>
Mukhang medyo kakaiba iyon, hindi ba? Nasaan ang mga opcode upang ihambing namin ang signature, public key at ang hash nito?
Hindi kami nagpapakita ng mga karagdagang operator dito, dahil alam ng mga node na tumatanggap ng transaksyon kung ano ang gagawin dito batay sa haba ng <public key hash>. Kalkulahin nila ang haba at mauunawaan na dapat itong patakbuhin sa parehong estilo tulad ng isang mahusay na naka-istilong P2PKH na transaksyon.
Hindi alam ng mga hindi na-upgrade na node kung paano bigyang kahulugan ang transaksyon sa paraang iyon, ngunit hindi mahalaga. Sa ilalim ng mga lumang patakaran, walang saksi, kaya't nagbasa sila ng walang laman na scriptSig at ilang data. Sinusuri nila ito at minarkahan itong wasto – hanggang sa alalahanin nila, puwedeng gastusin ng sinuman ang output. Ito ang dahilan kung bakit ang SegWit ay itinuturing na isang pabalik-katugmang
soft fork.
Pay-to-Witness-Script-Hash (P2WSH)
Ang Pay-to-Witness-Script Hash (P2WSH) ay ang bagong P2SH. Kung nagawa mo ito hanggang dito, marahil puwede mong malaman kung paano ito magmumukhang, ngunit tatakbo pa rin natin ito. Ang aming saksi ang karaniwang nais naming ilagay sa scriptSig. Sa isang P2WSH na nagbabalot ng isang transaksyon sa P2PKH, halimbawa, puwedeng magmukhang ganito:
<signature 1> <public key>
Narito ang aming scriptPubKey:
<OP_0> <script hash>
Ang parehong panuntunang humahawak. Basahin ng mga node ng SegWit ang haba ng script ng hash at tukuyin na ito ay isang output na P2WSH, na sinusuri nang katulad sa P2SH. Samantala, ang mga lumang node ay nakikita lang ito bilang isang output na kahit na sino ay puwedeng gumastos.
Sa artikulong ito, medyo natutunan namin ang tungkol sa mga block ng Bitcoin. I-buod natin sila ng mabilis:
| Uri ng script | Deskripsyon |
|---|
Pay-to-Pubkey (P2PK) | Nilo-lock ang mga pondo sa isang partikular na public key |
Pay-to-Pubkey-Hash (P2PKH) | Nilo-lock ang mga pondo sa isang partikular na public key hash (i.e., isang address) |
Pay-to-Script-Hash (P2SH) | Nilo-lock ang mga pondo sa hash ng isang script na puwedeng ibigay ng tatanggap |
Pay-to-Witness-Pubkey-Hash (P2WPKH) | Ang bersyon ng SegWit ng P2PK |
Pay-to-Witness-Script-Hash (P2WSH) | Ang bersyon ng SegWit na P2SH |
Kapag tinalakay mo nang mas malalim ang Bitcoin, sinisimulan mong maunawaan kung bakit mayroon itong labis na potensyal. Ang mga transaksyon ay puwedeng mabubuo ng maraming iba't ibang mga bahagi. Sa pamamagitan ng pagmamanipula ng mga binubuong block, ang mga user ay may kakayahang umangkop pagdating sa pagtatakda ng mga kundisyon sa kung paano at kailan puwedeng gugulin ang mga pondo.
