Mambabasa: beginner hanggang intermediate

Itali natin dito ang kagalingan ng pinagsama-samang sangkap ng Bitcoin. At bakit ito ang nagwawaging digital na salapi; pera para sa internet. Pag-usapan natin ng mas detalyado ang blockchain at balikan ang proof of work.

Pero simulan muna natin sa isa pang thought experiment na ipinahiwatig sa nakaraang kabanata.

Byzantine Generals Problem

Isa pang palaisipan sa mga distributed systems ay ang Byzantine Generals Problem. May mga hukbo na gustong umatake sa isang syudad. Sa senaryo na ito, 3 o higit pang hukbo ang dapat magkatugma-tugma sa oras ng pag-atake. Ang mensahe ay ipinagpapalagay na laging nakakarating. Subalit, ang hamon ay maaaring traydor ang ibang heneral. Malisyoso, “malicious” ang heneral na ganito. At tapat, “honest” ang matinong heneral.

Ang dapat makamit ng hukbo sa ganitong sitwasyon ay magkasang-ayon ang mga honest na heneral. At kung ang pinunong heneral ay tapat, masusunod ng mga honest din na heneral ang kanyang utos.

Halimbawa, si heneral 3 ay traydor. Sinabi ng heneral 1 sa 2 at 3 na umatake. Bilang gunggong, si heneral 3 ay sinabing umatras kay heneral 2. Malilito ang heneral 2, subalit basta sundin nya ang heneral 1, magkakasang-ayon sila ng desisyon.

Sa isang banda, halimbawa ay si heneral 1 ang traydor. Sinabi nito kay heneral 2 na umatake, subalit kay heneral 3 ay umatras. Ipinasa lang ni heneral 3 kay 2 ang mensaheng umatras. Sa 2 sitwasyong nabanggit, walang diperensya ang dating ng mensahe kay heneral 2 mapa 1 o 3 man ang traydor. Kailangan nitong mamili kung ano nga ba ang gagawin. At kapag ang heneral 1 nga ang traydor, ang heneral 3 ay malilito rin. Kapag ang gagawin ng heneral 2 at 3 ay sumunod nalang sa utos ng heneral 1, hindi na sila magkakasang-ayon bilang mga tapat na heneral. Kaya sa 3 heneral na nagpapasahan ng pasalitang mensahe (oral message), kahit isa lang ang traydor, hindi masosolusyunan ang Byzantine Generals Problem.

Subalit di gaya ng Two Generals Problem, ang Byzantine generals problem ay may solusyon. Sa naturang kondisyon, masosolusyonan ang Byzantine generals problem kapag ang dami ng mga malicious nodes, m ay mas mababa sa 1/3 ng dami ng lahat ng nodes, n:

n ≥ 3m + 1

Ito ay pinatunayan nina M. Pease, R. Shostak at L. Lamport. Kinokonsidera na dahil makakapagpasahan ng mensahe ang mga heneral sa isa’t isa, makakabuo ng listahan ng utos. Susundan ng mga tapat na heneral ang utos na pinakamaraming beses nabanggit sa listahan. Sa 4 na heneral, kapag 1 lang ang traydor, may solusyon sa Byzantine Generals Problem. Sa 7, 2 lang dapat ang traydor, atbp.

Isang implementasyon na gamit ang limitasyong nabanggit ay ang Practical Byzantine Fault Tolerance na pwedeng gamitin sa Network File System (NFS).

Subalit sa teorya, may solusyon ang Byzantine Generals Problem para sa hanggang 1/3 na malisyosong heneral. Ito ay kapag ang bawat mensahe ay dapat mayroong lagda/signature ng heneral. Ang lagda ay hindi kayang mapeke ng iba, at kayang maberipika ang pinanggalingan nito. At sa ibabaw nun, ay lahat ng heneral ay konektado sa isa’t isa.

Sa computing, alam na nating posible ang unforgeable signatures mula sa Kabanata 3, gamit ang cryptography. Pero makikita mo na mahirap itong makamit para sa malaking network. Doon, mas mainam na hindi kailangang lahat ng nodes ay konektado. Basta lang sapat ang dami ng honest nodes na konektado sa isa’t isa.

Sa tagal ng panahon, ang mga sistemang Byzantine Fault Tolerant ay nakadisenyo na hanggang m < (1/3)n.

Ang Solusyon ng Bitcoin

Naiangat ng Bitcoin ang limitasyon ng Byzantine Generals Problem sa pamamagitan ng 2 sangkap: Ang Blockchain at ang Proof-of-Work. Napag-usapan na natin ang ukol sa block rewards na parte ng Proof-of-Work sa Kabanata 5. Pero dahil nakapag-aral na tayo ng network at cryptography, maaari pa nating tignan nang mas malalim ang konsepto. Ngayon, simulan natin sa blockchain, tutal napag-usapan na rin lang natin ang mga blocks sa bandang huli ng kabanata 6.

Ang Blockchain

Ano ang Merkle Tree?

Pag-organisa ng block data

Napag-usapan na natin sa Kabanata 5 ang pagbuo ng transaksyon; at ang mga bagong transaksyon ay napupunta muna sa mempool. Mula rito, ang mga miners ay pumipili ng isasamang mga transaksyon na ilalagay sa isang block base sa fees at prayoridad. Kaya hindi garantisado ng oras kung kailan ginawa ang transaksyon na makukumpirma ito agad, lalo na kung mababa lang ang fee na katumbas.

Ang isang transaksyon ay makukumpirma kung:

• Ito ay naisama ng isang miner sa block, at ang miner na ito ang nanalo sa proof-of-work.
• Ang naturang block ay ang naipakalat sa mas maraming nodes, kaya ito ang madudugtungan ng mas maraming blocks sa susunod. At habang humahaba ang blockchain, mas tumataas ang seguridad na ang isang transaksyon sa mas malalim na block ay kumpirmado na.

Bahala na ang mga miner na mag-ayos ng transaksyon, basta:

• Pinakauna ang coinbase
• Kung sakaling nasa parehas na block maisasama ang mga transaksyon na konektado, mauuna dapat ang parent transaction na panggagalingan ng UTXO na gagamiting input ng isang child transaction.
• Ang isang UTXO ay isang beses lang pwede gamiting input ng transaksyon (bawal ang double spending)
• Ipagkakasya sa loob ng block ang kayang ipagkasya nang hindi lalagpas sa 4Mb, kasama na ang iba pang kinakailangang parte.

Merkle Tree

Nagiging posible ang pruned node at SPV client dahil sa pagkakakuha ng halaga ng block header. Ang karamihan sa laman ng block header ay: hash ng nakaraang block header at hash ng mga transaksyon sa loob ng block, na isang Merkle Root. Ibig sabihin, bumubuo ng Merkle Tree mula sa mga transaksyon sa loob ng block. Ano ang Merkle Tree?

Ang Merkle Tree ay paraan para sa secure pero mabilis na beripikasyon ng malaking data structure. Sa isang block, ang bawat transaksyon ay isang data. Ang data na ito ay idadaan sa double-SHA256 para magkaroon ng transaction ID (TXID). Kaya 256 bits o 32 bytes ang haba ng TXID. Ang mga TXID ay ililinya, kung saan una lagi sa pila ang coinbase transaction ID. Pagkalinya, ang bawat pares ng hash ay pagdudugtungin, at idadaan uli sa double-SHA256. Ang mga bagong hashes ay ipagpapares uli at dadaan sa parehas na pagpoproseso, hanggang isa nalang ang matira. Ang nag-iisang double-SHA256 na resulta ay ang Merkle Root. Ito ay 256 bits lang din.

Kung sakaling odd ang bilang ng transaksyon, pagdudugtungin lang ang TXID ng 2 beses bago idaan sa double-SHA256.

Identipikasyon ng Block: Block Header

Ang nakuhang Merkle root, ay kasama sa mga data na inilalagay sa Block Header. Ito ang metadata na nagsasalarawan ng laman ng block. Ang mga laman ng block header ay:

• Version
• Previous block hash – double-SHA256 ng nakaraang block header
• Merkle root
• Timestamp – Unix epoch time nung nabuo ang block
• Target – tumutukoy sa proof-of-work target nung ginawa ang block na ito
• Nonce – “number used only once” – pinkahuling arbitraryong data na nagresulta sa pagkamit ng proof-of-work target

Kaya ang mga lightweight/SPV clients ng Bitcoin network tulad ng wallets ay nakakakumpirma ng transaksyon na kailangan nitong ipaalam sa user. Malalaman nito gamit ang block headers kung pinakamahabang chain ang nakuha nitong impormasyon. Kapag kumbinsido na ito, kailangan lang alamin ng SPV client ang Merkle branch ng transaksyon para makumpirma na naisama ito sa isang block. Kaya nakakatulong rin na ipinapakita ng wallet software sa user kapag nakailang kumpirmasyon na ang transaksyon.

Istraktura ng Block

Ang data ng buong block ay nakaayos na:

• Block size
• Block header
• Transaction counter – kung ilang transaksyon ang naisama
• Transactions

Pagdudugtong ng blocks

Ang block hash ay double-SHA256 ng block header, at ginagamit na pamberipika ng mga nodes sa isang block. Ang isang node ay maaaring magtago o mag-index ng mga block hash sa disk nito, para madaling mahanap ang isang block. Sa blockchain kasi, ang block hash ay maitatago roon kapag naisama na sa block header ng susunod na block bilang: previous block hash. Ang previous block hash ang sangkap ng block header na syang nagkokonekta sa mga blocks para makabuo ng chain.

Bawat block ay may bahid ng nakaraang block. Kapag susundan ang bawat bahid pabalik, matutunton ang pinakauna o genesis block (block 0).

Sa mga bagong blocks na idinudugtong, hindi pa agad tiyak ang ayos blockchain. Ito ay dahil sa distribusyon ng mga nodes at miners ng network sa iba’t ibang panig ng mundo. May mga miners na makakabuo ng nais na block sa halos parehas na oras. Sa ganitong sitwasyon, may 2 o higit pang blocks na parehas ng block height. At habang kumakalat palang ang impormasyon sa mga nodes, nagkakaroon ng magkaibang kopya ng blockchain. Ang pangyayaring ito ay tinatawag na fork.

Paglaon ng ilan pang minuto, may bago uling block na mabubuo na madudugtong sa isa lamang sa mga nagkokompetensyang block sa parehas na height. Paglaon, magkakaalaman ang mga nodes sa kung ano ang pinakamataas ang proof-of-work, na sya ring pinakamahaba ang chain. Kaya, ang mga natalong blocks ay magiging stale blocks, na ididiskarga na ng nodes.

Dahil dito, inirerekomenda na wag agad gastahin ang Bitcoin na isang beses palang nakumpirma. Mas maiging ilang blocks muna ang lumipas para siguradong napabilang ang transaksyon mo sa block na mas piniling kasama sa best blockchain. Halimbawa, matapos ang 6 na blocks. Sa kaso ng mga miners, isang konsiderasyon ay maaari nang gastahin ang UTXO ng coinbase transaction matapos ang 100 blocks.

Compact Block Relay

Isa sa paraan upang mapabilis ang pagkalat ng block sa network ay ang paggamit ng compact block relay, na nasasaad sa BIP-0152. Ang bawat node kasi ay may mempool kung saan malaki ang tsansa na maraming pinagkaparehas sa ibang node. Kaya, ang miner ay maaaring magpasa lamang ng partial na block data. Ang makakatanggap na node ay maaaring makuha ang kabuuan ng block dahil sa naiipon nitong mempool transactions. At gayun din ang node na ito, kahit compact block lang muna ang ipasa sa iba. Hihingin nalang ang kulang kung sakaling hindi pa kayang buuin ang block mula sa sariling mempool transactions.

Ang compact block ay naglalaman ng:

• “HeaderAndShortIDs” – na naglalaman ng block header at mga short transaction IDs (sa halip na normal na TXID). Napapaloob din dito ang susunod:
• “PrefilledTransaction” – kung saan may coinbase at iba pang transactions na inaasahang wala pa ang ibang node.

Tignan nalang ang mga detalye sa BIP-0152 kung gusto mo pang siyasatin.

Para masagot ang binanggit sa huli ng Kabanata 6, ang high bandwidth mode ay eager push na stratehiya ng gossip protocol. Samantalang ang low bandwidth mode ay lazy push.

Ang compact block relay ay nakakatulong rin na gawing mas patas ang kompetisyon sa proof of work, dahil mas maagang nalalaman ng ibang miners na meron na palang block na bago. Mababawasan ang sayang na trabaho.

Proof of Work

Nabanggit sa ika-5 kabanata ang pangkalahatang ideya ng pagmimina. Palawakin pa natin ang konseptong ito.

Kinakailangang mapatunayan na tinrabaho ang pagkakabuo ng bawat block. Ito ay para ang mga malisyosong nodes na gustong modipikahin ang nakaraang blocks (para makadaya) ay kailangan ng mas malaking enerhiya kumpara sa mga tapat na nodes na gusto lang magdagdag ng bagong block.

Ang pagbuo ng block ay mag-uumpisa sa pagpili ng mga transaksyon mula sa memory pool ng miner/grupo ng miner/mining pool. Kasama na dun ang paglinya ng mga transaksyon para handa sa pagkuha ng Merkle tree. Sunod ay ang pagbuo ng coinbase transaction. Sunod ay ang pagbuo ng block header, kung saan kasama ang previous block header hash at Merkle root ng mga transaksyon. Sa pagbuo ng block header gagamit ng karagdagang enerhiya ang mining node. Bakit?

Target

Matatandaang kasama ang timestamp, target at ang nonce sa istraktura ng block header. Ang target ay ang numero na naglilimita sa halaga ng block header hash na dapat makuha sa isang pagkakataon.

Alam na natin na ang cryptographic hash function na gamit sa Bitcoin ay one-way hash function. Sa isang direksyon lang sya madaling kalkulahin (input —> output). Ibig sabihin sa mining, mula sa halaga ng target, hindi agad makakalkula pabalik ang double-SHA256 para mahanap ang sapat na nonce. Kaya trial-and-error o paulit-ulit na hulaan ang magaganap. Ang nonce ang pinapalitan sa bawat iteration. At maraming iteration ang bubunuin para maabot ang target. Dito napupunta ang bulto ng Proof-of-Work.

Ano ang halaga ng target?

Ang target ay malaking numero, bilang 256 bits ang nakatakdang haba nito — singhaba ng block header hash.

Sa block header, hindi nilalagay ang aktwal na halaga ng target. Sa halip, representasyon nito ang isinasaad. Matatandaan na 4 bytes (32 bits) lang ang nakasaad na espasyo para dito. Tignan ang target na ito sa block 800,000:

0000000000000000000538940000000000000000000000000000000000000000

Ito ay naka hexadecimal kaya 64 digits iyan. At bawat 2 digits ay 1 byte ang katumbas.

Ikumpara natin sa block header hash ng naturang block:

00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d72728a054

Mas maliit ito, diba? 02 < 05 sa unang significant byte (na naka-hexadecimal).

Ang representasyon ng target ay hango sa formula na:

target = coefficient x 2 ^{(8 x (exponent – 3))}

May simpleng paraan kapag naka hexadecimal ang formula na iyan para makuha ang target bits na representasyon:

• Ang exponent ay kung gaano kalayo ang coefficient mula sa dulo
• Ang coefficient ay 3 bytes na precision mula sa totoong target value.

Kaya, ang representasyon ng target noong panahon ng block 800,000 na kasya sa 4 bytes ay: 17053894 (sa hexadecimal)

Kung saan:

• 17 ang exponent: bilangin mo kung pang-ilan ang 05 mula sa pinakakanan ng target. Ika-46 ang 0 at ika-45 ang 5. Ibig sabihin, ika 23 na byte ito. Ang 23 sa hexadecimal ay 17.
• 053894 ang coefficient: unang 3 significant bytes na makikita mula sa pinakakaliwa ng target.

Difficulty Adjustment

Nakaprograma na kada 2016 blocks ay itinatakda ang bagong target. Kada 2 linggo bale. Uulitin natin ang ilang beses nang nabanggit sa aklat na ito: ang bawat block ay nabubuo sa loob ng average na 10 minuto. Ito ang nakatakdang tagal upang matapos ang Proof-of-Work. Ang target ay mas madaling makamit kapag:

• Mas marami ang nagkokompetensya sa pagmimina
• Mas malakas ang mga processor ng mga kompyuter na gamit

Kabaliktaran naman ang epekto kapag taliwas sa mga nabanggit ang sitwasyon. Ang tawag sa pagtatakda ng target sa kada 2 linggo ay: difficulty adjustment.

Ang formula ng difficulty adjustment ay simple lang:

Imu-multiply ang ratio ng actual na oras na nakonsumo sa pagbuo ng 2015 blocks sa 20,160 minutes. Sa halip na 2016 na nakaraang blocks ang pinagkukumparahan, may mali sa orihinal na Bitcoin software, at nakaugalian na ang 2015 blocks.

Kapag mas maliit ang halaga ng target, ito ay mas mahirap makamit. Makikita na ang block header hash ay magreresulta sa 32 bytes na maraming 0 sa umpisa. Mas madaling makamit ang mas malaking numero, o mas konting 0 sa umpisa, na target.

Halimbawa, ikumpara ang mga block header hash mula sa iba-ibang taon:

Block height	Taon	Block header hash (hexadecimal)
200,000	2012	000000000000034a7dedef4a161fa058a2d67a173a90155f3a2fe6fc132e0ebf
400,000	2016	000000000000000004ec466ce4732fe6f1ed1cddc2ed4b328fff5224276e3f6f
600,000	2019	00000000000000000007316856900e76b4f7a9139cfbfba89842c8d196cd5f91
800,000	2023	00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d72728a054

Sa paglaki ng Bitcoin network, ang halaga ng block header hash ay lumiliit (o dumadami ang 0s sa umpisa) – indikasyon na lumiliit ang target, o tumataas ang difficulty.

Halimbawa sa simpleng statistics

Para maintindihan bakit ganun, tignan natin ang halimbawa ng paglalaro ng 2 dice. Ang bawat resultang lalabas kapag nag-itsa tayo ng dice ay may probability. Halimbawa, ang laro natin ay mag-itsa ng 2 dice para makamit ang target na sum ng mga tuldok. May 36 na kombinasyon ng tuldok ang posible:

Dice 1 face	Dice 2 face	Sum	Dice 1 face	Dice 2 face	Sum
1	1	2	4	1	5
1	2	3	4	2	6
1	3	4	4	3	7
1	4	5	4	4	8
1	5	6	4	5	9
1	6	7	4	6	10
2	1	3	5	1	6
2	2	4	5	2	7
2	3	5	5	3	8
2	4	6	5	4	9
2	5	7	5	5	10
2	6	8	5	6	11
3	1	4	6	1	7
3	2	5	6	2	8
3	3	6	6	3	9
3	4	7	6	4	10
3	5	8	6	5	11
3	6	9	6	6	12

Kapag ang target ay sum na 12 pababa, aba, lagi nating makukuha ang target. Dahil 12 ang pinakamataas na sum na posible: tig 6 na tuldok bawat dice. Lahat ng iba pa ay mas maliit na sa 12. Halimbawa naman, liitan natin ang target: 10 pababa. May 3 kombinasyon na hindi maabot ang target na ito. Pero madali pa rin makamit ang target dahil 33 na kombinasyon, o 11/12 ang probabilidad na makukuha ito. Liitan pa natin sa 5 pababa ang target. Ayan, mas mahirap na itong maabot. Dahil 10 kombinasyon lang, mas maliit sa kalahati na ang probabilidad na makuha iyon: 5/18.

Extra Nonce

Nabanggit natin sa ika-5 kabanata na nakapaloob rin sa mga kasalukuyang input ng coinbase transactions ang extra nonce. Ito ay nag-ookupa sa espasyo ng “unlocking script” na wala namang saysay sa coinbase dahil walang ia-unlock. Sa kasalukuyang blocks, kung gagamit man ng extra nonce, ito ay susunod sa block height (na matapos ang BIP-0034 ay kinakailangan nang isama parati), at sa arbitraryong data na nilalagay ng ibang miners.

Sa taas ng pinagsamang hash rate ng mga miners ngayon, malamang pangkaraniwan nang ginagamit ang extra nonce sa mga iterasyon ng mining.

wTXID Commitment sa Coinbase

Pagpasok ng SegWit sa Bitcoin, may kinakailangang laman uli ang coinbase transaction, na nakalagay naman sa output. Ito ay ang paglalagay ng wTXID commitment.

Napag-usapan natin ang TXID sa unang parte ng kabanata na ito. Ang mga legacy TXID ay kasama ang witness data sa na double-SHA256. Subalit ang mga SegWit na TXIDs ay hindi isinasama ang witness sa hashing. Ito ay para nga matanggal ang transaction malleability na binanggit sa Kabanata 4.

Sa SegWit, may double-SHA256 pa rin na kasama ang witness. Ito ang witness transaction IDs (wTXID). Kapag kinuha ang Merkle Root ng mga wTXIDs, ito ay tinatawag na witness root hash. Ang witness root hash ay dudugtungan ng witness reserved value, bago idaan sa huling double-SHA256 para Mabuo ang wTXID commitment. Ito na ang inilalagay sa isa sa mga output ng coinbase transaction, bilang commitment. Ito ay para kung sakali mang may malisyosong miners na magpalit ng witness data sa kahit isang transaksyon, hindi na magbabangga ang witness root hash kapag bineripika ng ibang nodes. Kaya ang block ay magiging imbalido.

Tandaan: sa mga legacy transactions, ang TXID at wTXID nito ay parehas, dahil nga sa pagsunod nito sa lumang paraan ng pagkuha ng TXID.

Ano naman ang witness reserved value? Ito ay espasyo ng witness sa input ng coinbase transaction, na maaaring may gamit sa hinaharap. Pero sa ngayon, ito ay 32 bytes na 0 lamang:

0000000000000000000000000000000000000000000000000000000000000000

Balikan natin ang pagtingin sa coinbase transaction, na napag-usapan sa Kabanata 5:

Nasa OP_RETURN Output #1 ang wTXID commitment. Susunod sa OP_PUSHBYTES_36 ay:

• aa21a9ed – unang 4 bytes na constant para sa pag-indika na ito ay output na naglalaman ng commitment
• bfe7b90f093df4f15df23a94e4f57a2e135d6f826c96a5b91002656542b45dd3 – 32 bytes na wTXID commitment

Dahil sa mga nabanggit na alituntunin ng SegWit soft fork, nauuna ang pagkuha ng mga transaksyon sa mempool bago gawin ang coinbase transaction, kapag bumubuo ng block ang miner.

Miner Software

Dati, nakapaloob na sa Bitcoin Core software ang lahat ng aspeto ng Bitcoin, pati mining. Subalit paglaon, nung naging industriya na ito gamit ang napakaraming ASIC, wala nang silbi ang mining feature para sa nag-iisang node na may tipikal na CPU. Dahil dito, tinanggal na ang internal miner nung 2016 na update sa Bitcoin Core. Sa katunayan, sa bandang huli ng 2010 palang, hindi na kayang makipagkompitensya ng tipikal na CPU dahil sa paggamit ng mga graphics processing units (GPU). Kaya rin maaga palang sa kasaysayan ng Bitcoin ay nakonsidera na ang pooled mining.

Ang pooled mining ay kung saan maghahati-hati ang mga miners ng trabaho para matapos ang proof-of-work ng bagong block. Kapag ang isang pool service ay nanalo sa kompetisyon ng PoW, ipaghahati-hati nito sa mga miners ang pabuya, depende sa kanilang kontribusyon na trabaho.

Getwork

Ang unang paraan na ginawa para sa pooled mining ay ang getwork. Ito ay gumagamit ng JSON-RPC (JavaScript Object Notation – Remote Procedure Call) na dumadaan sa HTTP. Ang isang miner ay hihingi (getwork request) ng trabaho mula sa pool server. Sasagot ang pool server ng trabaho (getwork job o getwork response) na ipapagawa. Ang isang miner na matagumpay na makakahanap ng block header hash ay magpapadala ng HTTP POST request.

Hindi nakahabol ang getwork sa bilis ng progreso ng teknolohiya at kompetisyon sa mining. Kaya kinailangang palitan bandang 2012 pa lang ang RPC na ito. Isa pang isyu nito ay ang pool server ang nagdidikta ng mga isasamang transaksyon sa block. At ang mga miners ay susubukan lang makuha ang tamang halaga ng block header. May panganib ng centralization kapag ganun.

Getblocktemplate

Ang getblocktemplate ay RPC rin na dumadaan sa HTTP. Pinagbuti nito ang mga kakulangan ng getwork.

Ang miner ay hihingi muna ng template (template request) mula sa pool server. Ito naman ay sasagot ng template na may detalye ng mga kinakailangan para masimulan ang mining. Kasama na lagi sa pinapadala ang mga nirerekomendang transaksyon, di tulad sa getwork.

Ang isa pa sa pinagpabuti sa getblocktemplate ay: maaaring humingi ang miner ng mga mutations, o mga bagay na maaari nitong baguhin. Halimbawa, ang pagbago ng coinbase, pagdagdag/bawas ng transaksyon, o pagmodipika ng oras sa header. Kasama sa isasagot ng pool server ay ang mutable key, na isinasaad kung ano ang pinayagan nitong baguhin ng miner.

Subalit may kasabay na ginawang mining protocol ang ibang mga developers lalo na yung may mining pool na negosyo. At ang protocol na ito ang mas napili ng nakararaming miners kesa sa getblocktemplate.

Stratum

Sinolusyonan ng Stratum ang mga isyu sa getwork protocol sa paraang mas simple at nagreresulta sa mas mataas na performance ng mga mining pool, kumpara sa getblocktemplate. Kaya ito ang naging pamantayan ng mga pooled mining protocols.

Stratum V2 na ang gamit ngayon ng mga pool miners. Pero ilarawan muna natin ang V1 bago intindihin ang V2.

Stratum V1 (SV1)

Ang unang naresolba ng Stratum ay ang inefficiency ng paggamit ng layer ng HTTP sa pagpapasahan ng impormasyon. Sa Stratum, ang layer ng TCP ang diretsang ginagamit. Ang mining client ay magbubukas ng TCP socket na kombinasyon ng IP address at port nito, para kumonekta sa mining pool server sa tiyak na IP address at port naman nito. Ang pares ng TCP sockets na iyon ang end-to-end o direktang TCP connection sa pagitan ng miner at mining pool server. At nanatili itong bukas hanggat hindi bumibitaw ang miner.

Ang extra nonce sa coinbase transaction ay maaaring baguhin ng miner sa Stratum. Nakadulot ito ng pagpapabilis dahil kapag naubos na ang pagsubok ng nonce sa block header, maaaring dumiretso na sa pagbabago ng extra nonce ang miner sa halip na humingi uli ng getwork request para sa susunod na tsansang magmina.

Bumilis nga ang daloy ng impormasyon sa Stratum V1, subalit may mga aspeto ito na hindi kanais-nais paglaon. Halimbawa, ang JSON-RPC na mga mensahe ay hindi encrypted. Ito ay napatunayan ding may kahinaan sa mga pag-atake ng mga hackers tulad ng hashrate stealing at man-in-the-middle attacks.

Ang mga miners ay limitado pa rin ang kakayahan, kaya’t maaaring magdulot ng pagka centralized ng kapangyarihan sa mga malalaking mining pools.

Stratum V2 (SV2)

Matapos ang ilang taon, bandang 2019, ay iminungkahi ang Stratum V2 (SV2). Maraming pagpapabuti ang nalalaman nito, na syempre, ay naglalayong maging mas efficient at maging mas mataas ang seguridad ng operasyon ng mining. Layunin din ng Stratum V2 na maging standard at tumpak ang mga depinisyon, di gaya ng nangyari sa SV1.

Tinanggal na ang JSON sa Stratum V2. Gumagamit na ito ng binary protocol na malaki talaga ang itinipid sa data.

Para magkaroon ng decentralization, merong karagdagang mga papel at protocols sa operasyon ng mining.

3 protocols ang meron sa Stratum V2:

1. Mining Protocol – ito ang direktang pumalit sa SV1, at pangunahing protocol na ginagamit sa lahat ng senaryo. Ito kasi ang nagpapagana ng distribusyon ng trabaho (jobs) para sa mga miners, pagpasa ng mga ito ng resulta ng proof-of-work sa pool service, at ang distribusyon din ng mga pabuya. Ito ang protocol sa pagitan ng mining device at pool service, mining device at mining proxy, 2 proxies, o mining proxy at pool service.
2. Job Declaration Protocol – ito ay gamit ng miner (o mining farm) para ideklara ang block template nito sa mining pool. Ang komunikasyon ay sa pagitan ng 2 job declarators: sa miner side (job declarator client) at pool side (job declarator server). Kapag ang mining pool ay may kasamang job declarator server, nakapasa na dun ang distribusyon ng jobs. Kinukwenta nalang ng mining pool ang shares at distribusyon ng mga rewards.
3. Template Distribution Protocol – ito naman ang protocol para sa pagkuha ng block template na gagamitin sa pagmina ng susunod na block. Gamit ito sa komunikasyon ng template provider at job declarator, o kaya ng template provider diretso sa pool service. Ang Template Provider naman ay kumukuha ng mga transaksyon mula sa isang Bitcoin full node.

Ang mga papel o roles naman sa Stratum V2 ay:

• Mining device – ito ang device na nagmimina mismo, gaya ng isang ASIC.
• Pool service – Ito ang orihinal na gumagawa ng jobs, nagpapatunay at kwenta ng shares, at naniniguradong pinapakalat ang bagong block na matagumpay na namina. Gaya ng nabanggit kanina, kapag may job declarator server, hindi na gagawin ng pool service ang jobs.
• Mining proxy (opsyonal) – Ito ay server sa pagitan ng mining devices at pool service na nagsasama-sama ng koneksyon ng mga magkakagrupong miners, para mas efficient ang komunikasyon sa pool service. Kapag may job declarator, konektado dito ang mining proxy.
• Job declarator (opsyonal) – May 2 klase: job declarator client at job declarator server. Ang job declarator client ang tumatanggap ng pasadyang block templates, na idedeklara sa job declarator server. Magkakaroon ng negosasyon sa pagitan ng job declarator server at client, kung tanggap nga ng pool service ang sariling block template ng miners. Aalamin din ng job declarator server kung ano ang mga transaksyon na wala ito kung sakaling gamit ng job declarator client ang ibang block template.
• Template provider – ito ang gumagawa ng sariling block template, kaya madalas ay Bitcoin Core full node ito. Ipapasa nito sa job declarator ang block template. Para sa mga mas centralized na sistema, kagaya sa SV1, ang template provider ay magpapasa ng block template sa pool service mismo.

Hindi nagdedemanda ang Stratum V2 na mag-upgrade agad lahat ng mga miners sa firmware na ito. Kaya may mga pagsasaayos na nagkakaroon ng translation sa pagitan ng SV1 at SV2.

May apat (4) na pagsasaayos (configurations) ng devices sa Stratum V2.

Mas kanais-nais para sa decentralization ang Config A at B, kung saan maaaring pumili ng transaksyon ang mga miners, at hindi lang sumusunod sa napili ng Mining pool. Sa katunayan, maaaring mag configure ng mga alternatibong pool ang miners. Kapag hindi pumayag ang isang pool sa pagkakapili ng miner (o grupo ng miners/mining farm) ng transaksyon, maaaring lumipat ito sa alternatibong pool. At kapag wala talagang pumayag na pool server, magreresulta ito sa solo mining.

Para naman sa encryption at integridad ng mga mensaheng dumadaloy sa pagitan ng mga roles na magkalayo sa isa-t isa (hindi lokal na koneksyon), ito ang mga cryptographic primitives na gamit sa SV2:

• Elliptic Curve – secp256k1 curve at Schnorr signature scheme
• Hash function: SHA-256()
• Cipher function para sa authenticated encryption ng key, nonce, associated data, plaintext at ciphertext: Kombinasyon ng ChaCha20 (uri ng stream cipher) at Poly1305 bilang message authentication code.

Lahat ng iyan ay para makamit ang authenticated encryption with associated data (AEAD) scheme.

Isyu ng Ordinals

Lohikal lang para sa miners na ang mga transaksyon ay aayusin mula sa may pinakamataas na fees, pababa. Subalit dahil sa mga transaksyong tinuturing na spam, may mga miners na binabago ang software para sadyaing hindi isama ang mga spam kahit pa malaki ang fees nito. Hindi nangangahulugang sila ang tama, ito ay base sa paniniwala at prinsipyo kung san mas nararapat gamitin ang pagsisikap para sa Bitcoin.

Isang halimbawa ng spam ay ang mga ordinals, na non-fungible tokens (NFT) sa Bitcoin blockchain. Kung saan, pinupuno ng arbitraryong laman ang witness data o kaya naman ang output gamit ang OP_RETURN, ng text, image, video atbp. kasyang files.

Sa ordinal theory ni Casey Rodarmor, ang bawat sats ay may kaukulang pwesto na pwedeng gawan ng numbering scheme. Kaya natawag na ordinals ang mga NFT sa Bitcoin blockchain. Depende na sa tao kung ano ang gusto nyang ordinal. Pero ang mga peryodikong pangyayari sa Bitcoin tulad ng difficulty adjustment, halving, atbp. ay maaaring bigyan ng kahalagahan. Kaya, ang paglunsad ng ordinal ay mapapansing nag-uumpisa sa pagsasaad ng malaking transaction fee, para makuha nito ang unang pwesto sa block na sakto sa isang cycle.

Ang hindi pangkaraniwang laki ng transaction fee ay nakakatulong nga sa kita ng mga miners. Subalit, nagdudulot ito ng pag-eetsepwera ng mga normal na transaksyon. At dahil sa arbitraryong witness data o OP_RETURN data, nakakalaki ng memoryang gamit ng mga nodes para sa UTXO set at sa blockchain. Kaya, ang komunidad ng Bitcoin ay hati ang opinyon sa ordinals.

Konklusyon

Dahil sa 2 sangkap: Blockchain at Proof of Work, ang Bitcoin ay kayang tumakbo ng tama hanggat mahigit sa 50% ng nodes ay tapat. Nahigitan ang limitasyon ng Byzantine Generals Problem.

51% attack ang panganib na pwedeng harapin ng Bitcoin nung mga unang buwan nito. Pero dahil ilang taon na ang nakalipas at hindi pa naatake ng ganun ang Bitcoin network, halos imposible na sa liit ang tsansa na mangyari iyon. Sobrang daming enerhiya na ang nagamit para buuin ang kadena hanggang sa kasalukuyang block.

Sa mas bagong mga blocks, maaaring may mga miners na sumubok gamitin ang 51% attack para baguhin ang isang transaction history. Subalit, wala pang naging matagumpay na 51% attack sa Bitcoin network hanggang ngayon.

Ang proof of work ang nagbibigay ng isang mahalagang katangian ng blockchain: immutability o kalagayan na hindi nababago. Idagdag pa ang napag-usapan natin sa kabanata 6 na decentralized na katangian ng Bitcoin network. At talaga namang nakagawa si Satoshi Nakamoto ng sistema ng salapi na mahirap atakihin.

Makikita mo, minsan may mga bagay na sapat nang centralized, at mayroong iba na maiging decentralized. At sa pananaw ng may-akda, ang electronic na salapi ay dapat decentralized. Bitcoin ang naging kulminasyon ng pagdidisenyo ng decentralized at censorship-resistant na salapi.