Pagbuo ng mga Token, NFT, at DeFi sa Bitcoin
Ang proseso ng pagbuo ng mga token, NFT, at DeFi sa Bitcoin ay mas kumplikado kaysa sa inaasahan. Sa mga platform tulad ng Ethereum Virtual Machine (EVM) at iba pang smart contract platforms, ang mga smart contracts ay buong Turing-complete, na nagsasaad na madali lang magdagdag ng mga bagong tampok sa pamamagitan ng simpleng pag-deploy ng pasadyang kontrata. Sa Bitcoin, subalit, kailangang mag-ingat ang mga developer sa kanilang mga inobasyon upang hindi humantong sa hard fork, at kailangan nilang magtrabaho sa loob ng mga limitasyon ng kasalukuyang protocol.
Isa sa mga pangunahing salik na nagbibigay ng natatanging halaga sa Bitcoin ay ang pagsunod nito sa prinsipyo ng “originality,” kung saan ang pangunahing chain ay nakaranas ng kaunting pagbabago sa paglipas ng panahon. Sa kabila nito, ang Bitcoin ang kauna-unahang blockchain na umani ng malawak na pagtanggap at maraming teknolohiya na kalaunan ay ipinatupad sa mas nababaluktot na mga blockchain ay talagang may mga unang binhi sa Bitcoin. Halimbawa, ang mga NFT ay unang lumitaw sa Bitcoin sa anyo ng “Colored Coins“; ang konsepto ng State Channels ay kahawig ng disenyo sa kasalukuyang L1-L2 architecture; at ang Atomic Swaps ay naglatag ng pundasyon para sa modernong cross-chain bridges.
Nailahad na namin ang ilan sa mga pag-unlad na ito sa nakaraang artikulo na “Nagsisimula Mula sa Bitcoin: Ang Tunay na Pinagmulan ng DeFi.” Upang tunay na maunawaan ang walang kapantay na halaga ng Bitcoin bilang pundasyon ng Botanix at iba pang mga chain ng Bitcoin, mahalagang suriin kung paano ang mga unang inobasyon na ito ay naglatag ng daan para sa kasalukuyang ekosistema.
Functional Theory ng Bitcoin
Paggalugad sa Functional Theory ng Bitcoin: Nakakayanan ba ng Bitcoin ang isang kumplikadong ekosistema? Nang ilunsad ang Bitcoin noong 2009, kasama nito ang isang built-in na scripting language na hindi lamang nagpayagan ng mga simpleng transaksyon kundi pati na rin ng mas kumplikadong operasyon tulad ng multi-signature at time-lock. Tinukoy ni Satoshi Nakamoto na ang mga unconfirmed transactions na gumagamit ng nLockTime at sequence numbers ay maaaring ma-update ng maraming beses sa pagitan ng dalawang partido para sa high-frequency transactions, at tanging ang huling estado lamang ang isusulat sa chain.
Ang Bitcoin Script ay isang kawili-wiling mekanismo: ito ay Turing-incomplete, na naglilimita sa kakayahan nito; ngunit nananatili itong simple at ligtas. Samakatuwid, kapag nagbuo ng anumang kumplikadong function sa Bitcoin, kailangan itong idisenyo ng mga developer sa loob ng balangkas na ibinigay ng Script. Naglalaman ito ng malaking bilang ng mga opcode para sa pag-program ng iba’t ibang aksyon, na sa huli ay isusulat sa data ng transaksyon. Ang Bitcoin Script ang scripting language na ginagamit ng Bitcoin upang tukuyin ang mga kondisyon para sa paggastos ng mga coin. Maaaring isipin ang Script bilang isang recipe—isang hanay ng mga hakbang upang mag-bake ng cake. Ang mga Opcodes ay ang mga building block ng wikang ito—sila ang pangunahing tagubilin na ginagamit ng mga programmer kapag sumusulat ng mga script, tulad ng “haluin” at “initin.”
“Isang pag-aaral ng NCC Group ang nag-summary sa 156 iba’t ibang script patterns at nagsagawa ng detalyadong pagsusuri ng estruktura ng mga script na ito.”
Kaya, maaari ba tayong subukang gumamit ng Script upang ayusin ang mekanismong katulad ng DeFi sa Bitcoin? Magpatuloy tayo sa paggalugad sa susunod na hakbang.
Mekanismo ng Pautang
Tulad ng nabanggit kanina, ang mga opcodes ay maaaring pagsamahin upang bumuo ng isang serye ng maliliit na chains ng mga utos upang makamit ang mas kumplikadong pag-uugali. Halimbawa, maaaring bumuo ang mga developer ng mga kumplikadong script na may mga function ng loan contract sa pamamagitan ng pagsasama ng mga opcodes. Maaaring maabot ito sa pamamagitan ng kumbinasyon ng mga time-lock at multi-signatures: Ang mga tool na ito ay maaaring magsagawa ng mga “bilateral escrow contracts na may timeouts.”
Halimbawa, ipagpalagay natin na nagbibigay si Alice ng BTC bilang collateral, at nagpautang si Bob sa kanya ng stablecoins offline. Umaasa sila na magtakda ng mga tuntunin sa pamamagitan ng kontrata: Kung hindi nagbayad si Alice sa tamang oras, makukuha ni Bob ang kanyang BTC; kung nagbayad siya sa tamang oras, ang BTC ay mai-unlock at ibabalik kay Alice. Upang magawa ito, maaari silang gumamit ng 2-of-2 multi-signature output (parehong kailangang pumirma nina Alice at Bob upang ma-access ang pondo). Pagkatapos, maaari nilang i-set ang script logic: kung ang pautang ay hindi pa rin mababayaran pagkatapos umabot sa isang tiyak na block height, tanging si Bob lamang ang makakabili ng pondo.
Subalit, may isang pangunahing hamon dito: ang Bitcoin mismo ay hindi makakalkula ng interes, mag-monitor ng collateralization rates, o ipatupad ang mga liquidations. Anumang pagbabayad ng interes ay dapat gawin off-chain o sa tulong ng mga pre-signed transactions (na maaaring maging kumplikado sa praktis). Kung bumagsak ang presyo ng BTC habang nasa panahon ng pautang, ang Bitcoin script mismo ay hindi kailanman makakaalam at hindi maaaring awtomatikong i-trigger ang liquidation. Upang maabot ang function na ito, kinakailangan ang isang oracle o off-chain protocol. Nang walang oracle, ang kontrata ay maaaring gumawa lamang ng mga paghuhusga batay sa huling expiration time. Samakatuwid, mahirap ipatupad ang trustless BTC-collateralized stablecoin lending sa Bitcoin layer. Ang kasalukuyang mga pamamaraan ay kadalasang umaasa sa mga pinagkakatiwalaang ikatlong partido o gumagamit ng atomic swap mechanisms sa ibang mga chain upang makamit ito sa hindi tuwirang paraan.
Mga Tampok ng AMM
Tulad ng nabanggit sa itaas, ang mga mekanismo ng pautang at staking ay maaaring ipatupad sa teorya gamit ang Bitcoin Script, ngunit sa praktis, mas mababa ang kahusayan nila. Gayunpaman, maaari pa rin nating tukuyin kung posible bang makabuo ng mas kumplikadong mekanismo tulad ng automated market makers (AMMs) sa Bitcoin. Naglalaman ang Bitcoin Script ng mga mathematical opcodes tulad ng OP_ADD, OP_SUB, at OP_MUL (bagaman ilan dito ay na-disabled), pati na rin ng mga comparison opcodes tulad ng OP_LESSTHAN.
Sa teorya, maaaring gamitin ang mga function na ito upang ipatupad ang lohika ng pagkalkula ng presyo. Maaaring makabuo ang mga developer ng script na may nakatakdang presyo o isang set ng mga paunang natukoy na katanggap-tanggap na mga presyo, ngunit imposibleng dinamikong itama ang presyo pagkatapos ng bawat transaksyon. Ang dahilan ay gumagamit ang Bitcoin ng UTXO model, at bawat transaksyon ay bumubuo ng isang bagong UTXO at script, kaya ang bawat posibleng estado ay dapat pre-kalkulahin o isang kontrata ay dapat i-redeploy pagkatapos ng bawat transaksyon.
Isang mahalagang salik sa pagpapatupad ng AMM ay ang kakayahang makipagpalitan ng mga asset. Sa teorya, sinusuportahan ng Bitcoin ang atomic swaps, na maaaring itayo sa anyo ng order books sa halip na mga liquidity pools. Ang katulad na pag-uugali ng AMM ay maaaring i-simulate sa pamamagitan ng pagbuo ng isang serye ng HTLC (hash time lock contracts) o pag-isyu ng mga pending orders sa iba’t ibang puntos ng presyo upang bumuo ng isang static na automatic market making system (katulad ng yield curve).
Gayunpaman, ang pagpapanatili ng ganitong sistema ay napaka-buram, at kailangan ang script na i-update nang manu-mano at ang UTXO ay muling ipagkaloob pagkatapos ng bawat transaksyon, na may napakataas na on-chain na gastos. Samakatuwid, bagaman sa teorya ay posible na makabuo ng isang AMM, may mas malaking problema sa praktika: mayroong isang natatanging asset, ang BTC, sa Bitcoin mainnet. Bagaman ang mga protocol tulad ng Omni ay nagbigay ng mekanismo ng token, ang mga asset na ito ay umiiral sa metadata ng transaksyon at hindi maaaring makilala at maproseso ng script.
Pinalawak na Functionality ng Script
Ang mga nabanggit na puntos ay nagpapaliwanag kung bakit ang Bitcoin ay regular na sumasailalim sa malalaking update upang mapabuti ang kakayahan nito. Isa sa mga mahalagang update ay ang Taproot, na ipinakilala sa pamamagitan ng soft fork ngunit talagang pinabago ang paraan ng pag-design ng Script.
Mekanismo ng OP_SUCCESS ng Taproot: Sa pagpapakilala ng Taproot upgrade (BIP 342), maraming mga na-disabled o nakalaan na opcodes na-convert sa OP_SUCCESS na opcodes sa Tapscript (ibig sabihin, SegWit v1 scripts). Ang OP_SUCCESS ay nangangahulugan na basta’t ang opcode ay na-execute, ang script ay tatapos ng matagumpay. Ang disenyo na ito ay nagpapadali at nagpapalakas ng seguridad sa pagdagdag ng mga bagong opcodes sa pamamagitan ng mga soft forks.
“Ang mga hinaharap na soft forks ay maaaring muling tukuyin ang pag-uugali ng isang tiyak na OP_SUCCESS opcode.”
Partikular sa Tapscript, kung ang halaga ng opcode ay nasa isang tiyak na hanay (halimbawa: 0x50, 0x62, 0x7E-0x81, 0x83-0x86, 0x89-0x8a, 0x8d-0x8e, 0x95-0x99, 0xbb-0xfe), ito ay ituturing na OP_SUCCESSx. Kapag nakatagpo ang mga opcodes na ito, ang script ay walang kondisyon na itinuturing na matagumpay at ang iba pang lohika ay papabayaan.
Ang mekanismong ito ay pumapalit sa lumang OP_NOP (walang opcodes) na paraan ng upgrade, na nagdadala ng mas mataas na seguridad at kakayahang umangkop. Sa pangkalahatan, ang lahat ng mga opcodes na hindi nakalista bilang “magagamit” ay o nakalaan o na-convert upang palaging magbigay ng matagumpay na OP_SUCCESS sa Taproot.
Isang mahalagang aspeto ay ang mga opcodes ay maaaring maiproseso sa pamamagitan ng proseso ng BIP (Bitcoin Improvement Proposal), at may ilang makapangyarihang mungkahi na nasa ilalim ng pagsusuri o tinanggihan. Ang ilan sa mga mungkahi na ito, kung tatanggapin, ay malaki ang posibilidad na palawakin ang kakayahan ng Bitcoin, na nagpapahintulot dito na magsagawa ng mas kumplikadong operasyon. Ngunit bakit hindi pa na-aprubahan ang mga opcodes na ito? Ang pangunahing dahilan ay maaaring dahil sa ang komunidad ng mga developer ng Bitcoin ay labis na maingat sa pagpapanatili ng orihinal na anyo ng Bitcoin.
Sa isang banda, ang pagpapakilala ng mga bagong tampok ay talagang makatutulong sa pagpapabuti ng usability at scalability ng Bitcoin; ngunit sa kabilang banda, ang Bitcoin mismo ay isang network na dinisenyo upang maging “mabagal,” at ang “katagalan” na ito ay, sa ilang lawak, itinuturing din bilang “orihinal” na tampok nito.
Stablecoins at ang Ekosistema ng Bitcoin
Ang mga stablecoin ay naging isang pangunahing bahagi ng kahit anong Web3 ecosystem, kahit na ang mga ito ay hindi tuwirang kaugnay sa DeFi. Pinapayagan nila ang mga gumagamit na pamahalaan ang mga panganib ng pagkasumpungin at maglipat ng pera nang walang pag-aalala sa mga pagbabago sa presyo ng asset. Tulad ng nabanggit kanina, ang Bitcoin network ay palaging naghahanap ng balanse sa pagitan ng functional simplicity at ang dami ng data na maaaring maitala.
Kawili-wili, ang pinakamaagang pagtatangka na mag-isyu ng mga asset sa Bitcoin ay naabot sa pamamagitan ng pagbuo ng “Colored Coins,” na may pagkakahawig sa mga NFT. Noong 2012, iminungkahi ni JR Willett ang ideya ng pag-iisyu ng mga bagong asset sa Bitcoin at inilarawan ang konsepto ng “colored coins.” Siya ay tumulong na gumawa ng Mastercoin protocol (na kalaunan ay pinalitan ng pangalan na Omni), na naglatag ng pundasyon para sa tokenization ng mga asset sa Bitcoin (kabilang na ang mga token na nakasalalay sa mga fiat currencies).
Dahil walang direktang “token” opcode sa karaniwang Bitcoin Script, ang mga developer ay maaari lamang mag-embed ng token metadata sa mga output ng transaksyon gamit ang tulong ng OP_RETURN (ginagawang hindi magagamit ang output at may kasamang data). Bago na-standardize ang OP_RETURN, kahit na ang multi-signature scripts ay ginamit bilang isang “paikot-ikot na paraan” upang i-encode ang data.
Ang Bitcoin Script mismo ay hindi maaaring ipatupad ang anumang mga patakaran ng token—ang mga patakaran ay pinapanatili ng off-chain software na responsable para sa pag-parse ng mga transaksyon ng Bitcoin. Ang mga protocol tulad ng Colored Coins, Omni Layer (dating Mastercoin), Counterparty, at Open Assets ay kumakatawan sa mga token sa pamamagitan ng “pagkukulay ng ilang satoshis o UTXOs.” Halimbawa, ginagamit ng Open Assets protocol ang isang OP_RETURN output na naglalaman ng metadata na tumutukoy sa bilang ng mga token at ang asset ID.
Sa katunayan, ang blockchain ng Bitcoin mismo ay hindi kaalaman sa pag-iral ng “mga token”—pinoproseso lamang nito ang data. Ang bisa ng mga token (hal. supply, ownership) ay sinusubaybayan ng mga panlabas na wallet pagkatapos i-parse ang OP_RETURN data. Mahalaga ring banggitin na ang OP_RETURN ay may limitasyon sa sukat ng data. Itinatakda ng karaniwang patakaran ng Bitcoin Core client na ang bawat OP_RETURN output ay maaaring magkaroon ng hanggang 80 bytes ng arbitrary data. Ang data na lumampas sa 80 bytes ay ituturing na “non-standard transaction” at hindi ipapasa sa default.
Sa teorya, isang transaksyon ay maaaring maglaman ng maraming OP_RETURN outputs upang dagdagan ang dami ng kasamang data (hanggang 80 bytes bawat isa), ngunit upang maiwasan ang mga spam transactions, ang kasalukuyang standard relay policy ng Bitcoin ay kadalasang nagpapahintulot lamang sa bawat transaksyon na magkaroon ng isang OP_RETURN output.
Ang kakayahang i-embed ang metadata sa mga transaksyon ng Bitcoin ay nagdulot ng paglikha ng Mastercoin protocol noong 2012, na kalaunan ay pinalitan ng pangalan na Omni. Ang Omni Layer ay nagkaroon ng isang pangunahing papel sa maagang operasyon ng Tether at naging pangunahing transmission protocol para sa unang batch ng mga transfer ng USDT. Sa loob ng isang panahon ng kalagitnaan ng 2010s, ang USDT batay sa Bitcoin (Omni) ang pinakamatibay na stablecoin sa merkado, lalo na malawak na ginagamit sa mga exchanges tulad ng Bitfinex. Ang mga transaksyon ng Omni ay sa katunayan ay standard na mga transaksyon ng Bitcoin na may karagdagang metadata. Ang Omni ay kalaunan ay bumuo ng maraming iba’t ibang implementasyon na kategorya, na bumubuo ng sariling landas ng teknikal na ebolusyon.
