Maaari bang Suportahan ng SPV ang isang Bilyong Gumagamit ng Bitcoin ? Pag-size ng isang Scaling Claim

Si Jameson Lopp ay isang software engineer sa BitGo, tagalikha ng statoshi.info at tagapagtatag ng bitcoinsig.com.

Sa piraso ng Opinyon na ito, malalim ang pagsisid ni Lopp sa mga pag-aangkin na ligtas na alisin ang limitasyon sa laki ng block ng bitcoin at sa halip ay umasa sa mga umiiral na pamamaraan ng "pinasimpleng pag-verify ng pagbabayad" (SPV).

Ang isang bagong paghahabol ay ipinagpapatuloy sa debate sa pag-scale ng Bitcoin .

Naririnig namin na ligtas na alisin ang limitasyon sa laki ng bloke dahil ang Bitcoin ay madaling i-scale sa malalaking sukat ng block na susuportahan ang bilyun-bilyong user sa pamamagitan ng umiiral na mga pamamaraan ng "pinasimpleng pag-verify ng pagbabayad" (SPV). Kumbaga, napaka-scalable ng SPV dahil sa maliit na halaga ng data na kailangan ng isang SPV client na mag-imbak, magpadala at tumanggap.

Isaalang-alang natin ang claim na ito at suriin ito mula sa maraming pananaw.

Paano gumagana ang SPV

Satoshi

inilarawan ang mataas na antas ng disenyo para sa SPV sa Bitcoin puting papel, kahit na T ito ipinatupad hanggang makalipas ang dalawang taon nang gumawa si Mike Hearn BitcoinJ.

Sa pamamagitan ng pagtatapon ng mga transaksyon na T nauugnay sa wallet ng kliyente ng SPV, nakakuha ito ng malaking pagtitipid sa paggamit ng disk. Tumagal ng isa pang 18 buwan para sa BIP 37 na mai-publish, na nagbibigay ng detalye para sa Bloom filtering ng mga transaksyon, kaya umaasa sa Merkle root ng block header upang patunayan ang pagsasama ng isang transaksyon sa isang bloke gaya ng inilarawan ni Satoshi. Nagbigay ito ng lubos na pagbawas sa paggamit ng bandwidth.

Kapag nag-sync ang isang kliyente ng SPV sa Bitcoin network, kumokonekta ito sa ONE o higit pang ganap na nagpapatunay ng mga Bitcoin node, tinutukoy ang pinakabagong block sa dulo ng chain, pagkatapos ay hinihiling ang lahat ng block header na may command na "getheaders" para sa mga bloke mula sa huling block na na-sync nito hanggang sa dulo ng chain.

Kung ang kliyente ng SPV ay interesado lamang sa mga partikular na transaksyon na nauugnay sa isang pitaka, gagawa ito ng isang Bloom filter batay sa lahat ng mga address kung saan ang pitaka nito ay nagmamay-ari ng mga pribadong key at magpapadala ng "filterload" na command sa buong (mga) node upang malaman nilang ibalik lamang ang mga transaksyon na tumutugma sa filter.

Pagkatapos i-sync ang mga block header at posibleng mag-load ng Bloom filter, ang SPV client ay nagpapadala ng "getdata" na command para Request ang bawat solong (posibleng na-filter) na block na hindi nila napanood mula noong huling beses silang huling online, nang sunud-sunod.

Kapag naka-sync na ang kliyente, kung mananatili itong konektado sa (mga) buong node na peer, makakatanggap lang ito ng mga mensahe ng imbentaryo ng "inv" para sa mga transaksyong tumutugma sa na-load na filter ng Bloom.

SPV client scaling

Mula sa pananaw ng isang kliyente, ang pag-filter ng Bloom ay isang napakahusay na paraan upang makahanap ng mga nauugnay na transaksyon sa blockchain, habang gumagamit ng kaunting mapagkukunan ng CPU, bandwidth at espasyo sa disk.

Ang bawat Bitcoin block header ay 80 bytes lamang, kaya sa oras ng pagsulat ay 38 megabytes lamang ng data para sa buong walong-plus na taon na kasaysayan ng blockchain. Bawat taon (humigit-kumulang 52,560 block), nagdaragdag lamang ng 4.2 megabytes, anuman ang laki ng mga bloke sa blockchain.

Ang puno ng Merkle na ginagamit upang patunayan ang pagsasama ng isang transaksyon sa isang bloke ay napakahusay din ng mga kaliskis. Dahil ang bawat bagong "layer" na idinaragdag sa puno ay nagdodoble sa kabuuang bilang ng "mga dahon" na maaari nitong katawanin, T mo kailangan ng napakalalim na puno upang mapatunayan ang pagsasama ng isang transaksyon, kahit na sa gitna ng isang bloke na may milyun-milyong mga transaksyon.

sa pamamagitan ng Mastering Bitcoin

Ang istruktura ng data ng Merkle tree ay napakahusay na maaari itong kumatawan sa 16 milyong mga transaksyon na may lalim na 24 lamang - ito ay sapat na upang kumatawan sa isang 8GB na bloke. Gayunpaman, ang patunay ng Merkle tree para sa naturang transaksyon ay nananatiling mas mababa sa 1KB ang laki!

📷sa pamamagitan ng Mastering Bitcoin

Malinaw na mula sa pananaw ng kliyente ng SPV, ang network ng Bitcoin ay maaaring i-scale sa mga multi-gigabyte na bloke at ang mga kliyente ng SPV ay magkakaroon ng kaunting problema sa pagproseso ng maliit na halaga ng data na kinakailangan – kahit na sa isang mobile phone na may koneksyon sa 3G.

Ngunit sayang, ang pag-scale ng Bitcoin network ay hindi ganoon kadali.

SPV server scaling

Bagama't hindi kapani-paniwalang mahusay ang SPV para sa mga kliyente, hindi ito totoo para sa server - iyon ay, ang buong (mga) node kung saan humihiling ang mga kliyente ng SPV. Ang pamamaraang ito ay nagpapakita ng mahinang scalability para sa maraming mga kadahilanan.

Ang mga node sa network ay kailangang magproseso ng napakalaking dami ng data upang maibalik ang mga resulta para lamang sa isang peer, at dapat nilang ulitin ang gawaing ito sa bawat bloke para sa bawat peer na humihiling nito. Mabilis na nagiging bottleneck ang disk I/O.

Dapat i-sync ng bawat kliyente ng SPV ang buong blockchain mula sa huling pagkakataon na nakipag-ugnayan ito sa network, o, kung naniniwala itong napalampas nito ang mga transaksyon, kakailanganin nitong i-scan muli ang buong blockchain mula noong petsa ng paglikha ng wallet. Sa pinakamasamang kaso, sa oras ng pagsulat, ito ay humigit-kumulang 150GB. Dapat i-load ng buong node ang bawat bloke mula sa disk, i-filter ito sa mga detalye ng kliyente at ibalik ang resulta.

Dahil ang mga blockchain ay isang anyo ng append-only ledger, ang halagang ito ay hindi titigil sa paglaki. Kung walang malawakang pagbabago sa protocol, ang blockchain pruning ay hindi tugma sa BIP 37 – inaasahan nito na ang lahat ng block ay magagamit sa lahat ng buong node na nag-a-advertise ng NODE_BLOOM.

Ang mga kliyente ng BIP 37 SPV ay maaaring magsinungaling sa pamamagitan ng pagtanggal. Upang labanan ito, ang mga kliyente ng SPV ay kumonekta sa maraming node (karaniwang apat) kahit na hindi pa rin ito isang garantiya – ang mga kliyente ng SPV ay maaaring hatiin sa pangunahing network sa pamamagitan ng pag-atake ng Sybil. Pinapataas nito ang load sa network ng mga full node sa pamamagitan ng apat na factor.

Para sa bawat konektadong SPV client na na-synchronize sa dulo ng blockchain, ang bawat papasok na block at transaksyon ay dapat na isa-isang na-filter. Ito ay nagsasangkot ng di-napapabayaang dami ng oras ng CPU at dapat gawin nang hiwalay para sa bawat konektadong SPV client.

Crunching ang mga numero

Sa oras ng pagsulat ay may humigit-kumulang 8,300 buong node na tumatakbo na tumatanggap ng mga papasok na koneksyon; humigit-kumulang 8,000 sa kanila ang nag-a-advertise ng NODE_BLOOM at sa gayon ay may kakayahang maghatid ng mga kahilingan mula sa mga kliyente ng SPV. Ngunit, gaano karaming mga kliyente ng SPV ang makatwirang suportahan ng kasalukuyang bilang ng mga buong node na nakikinig?

Ano ang kinakailangan upang ang network ay mabuo ng mga buong node na maaaring suportahan ang parehong isang bilyong pang-araw-araw na gumagamit at mga bloke na sapat na malaki upang ma-accommodate ang kanilang mga transaksyon?

Nagde-default ang Bitcoin CORE sa maximum na 117 papasok na koneksyon, na lilikha ng upper bound ng 936,000 available na socket sa network. Gayunpaman, ang karamihan sa mga socket na ito ay natupok na ngayon.

Ang bawat buong node ay kumokonekta sa walong iba pang buong node bilang default. Ang developer ng Bitcoin CORE si Luke-Jr's (napakagaspang) bilang ng node tinatantya ang 100,000 kabuuang mga node sa oras ng pagsulat; 92,000 dito ay T gumagawa ng mga socket na magagamit para sa mga kliyente ng SPV. Kumakain ito ng 800,000 available na socket para lang sa mga full node, na nag-iiwan lamang ng 136,000 socket na available para sa mga kliyente ng SPV.

Ito ay humantong sa akin upang tapusin na sa paligid ng 85 porsiyento ng mga magagamit na socket ay natupok ng network mesh ng buong node. (Karapat-dapat tandaan na ang paraan ng pagtatantya ni Luke-Jr ay T matukoy kung gaano karaming oras ang ginugugol ng mga hindi nakikinig na node online; tiyak na ang ilan sa mga ito ay nadidiskonekta at muling kumonekta sa pana-panahon.)

Aking node na kapangyarihan statoshi.info may average na 100 buong node (walong papalabas, 92 papasok) na mga kapantay at 25 kliyente ng SPV. Iyon ay 80 porsyento ng mga magagamit na socket na natupok ng buong node.

Kung gusto nating kahit 1 bilyong kliyente ng SPV ay makagamit ng ganoong sistema, kakailanganing magkaroon ng sapat na buong mapagkukunan ng node na magagamit upang maserbisyuhan ang mga ito – mga socket ng network, mga cycle ng CPU, disk I/O, at iba pa. Maaari ba nating gawin ang matematika?

Upang mabigyan ng pakinabang ng pagdududa ang mga claim sa pag-scale ng SPV, gagamit ako ng ilang konserbatibong pagpapalagay na ang bawat isa sa bilyong user ng SPV ay:

– Magpadala at tumanggap ng ONE transaksyon bawat araw.

– I-sync ang kanilang wallet sa dulo ng blockchain isang beses bawat araw.

– Magtanong ng apat na magkakaibang node kapag nagsi-sync upang bawasan ang mga pagkakataong magsinungaling sa pamamagitan ng pagtanggal.

Ang isang bilyong transaksyon kada araw, kung pantay-pantay ang paghahati-hati (na tiyak na hindi mangyayari) ay magreresulta sa humigit-kumulang 7 milyong mga transaksyon sa bawat bloke. Dahil sa mahusay na scalability ng mga Merkle tree, mangangailangan lamang ito ng 23 hash para mapatunayan ang pagsasama ng isang transaksyon sa naturang block: 736 bytes ng data at isang average na 500 bytes para sa transaksyon.

Magdagdag ng isa pang 12KB na halaga ng mga block header bawat araw at ang isang SPV client ay gagamit pa rin ng humigit-kumulang 20KB na halaga ng data bawat araw.

Gayunpaman, 1 bilyong transaksyon bawat araw ay bumubuo ng 500GB na halaga ng blockchain data para sa buong node na iimbak at iproseso. At sa tuwing kumokonekta ang isang SPV client at humihiling na maghanap ng anumang mga transaksyon para sa wallet nito sa nakalipas na araw, apat na buong node ang dapat magbasa at mag-filter ng 500GB ng data bawat isa.

Alalahanin na kasalukuyang mayroong humigit-kumulang 136,000 socket na magagamit para sa mga kliyente ng SPV sa network ng 8,000 SPV-serving full node. Kung gumagamit ng apat na socket ang bawat SPV client, 34,000 client lang ang maaaring mag-sync sa network sa anumang oras. Kung mas maraming tao ang online nang sabay-sabay kaysa doon, ang ibang mga user na sinusubukang buksan ang kanilang wallet ay magkakaroon ng mga error sa koneksyon kapag sinusubukang mag-sync sa dulo ng blockchain.

Kaya, para masuportahan ng kasalukuyang network ang 1 bilyong user ng SPV na nagsi-sync nang isang beses bawat araw, habang 34,000 lang ang maaaring mag-sync sa anumang oras, iyon ay 29,400 "grupo" ng mga user na dapat kumonekta, mag-sync, at magdiskonekta: ang bawat user ay kailangang makapag-sync sa nakaraang araw ng data sa loob ng wala pang tatlong segundo.

Nagdudulot ito ng BIT palaisipan dahil mangangailangan ito sa bawat buong node na makapagbasa at makapag-filter ng 167GB ng data bawat segundo bawat kliyente ng SPV nang tuluy-tuloy. Sa 20 SPV client bawat buong node, iyon ay 3,333GB bawat segundo. Hindi ko alam ang anumang mga storage device na may kakayahang tulad ng throughput. Posibleng gumawa ng malaking RAID 0 array ng mga high-end na solid state disk na maaaring makamit ang humigit-kumulang 600MB/s bawat isa.

Kakailanganin mo ng 5,555 drive upang makamit ang target na throughput. Ang naka-link na halimbawang disk ay nagkakahalaga ng $400 sa oras ng pagsulat at may humigit-kumulang 1TB na kapasidad – sapat upang mag-imbak ng dalawang araw na halaga ng mga bloke sa teoretikal na network na ito. Kaya, kakailanganin mo ng bagong hanay ng mga disk tuwing dalawang araw, na gagastos sa iyo ng mahigit $2.2 milyon – ito ay umaabot sa mahigit $400 milyon para mag-imbak ng isang taon na halaga ng mga bloke habang natutugunan pa rin ang kinakailangang read throughput.

Siyempre, maaari nating paglaruan ang mga pagpapalagay na ito at mag-tweak ng iba't ibang numero. Maaari ba tayong gumawa ng isang senaryo kung saan ang halaga ng node ay mas makatwiran?

Subukan natin:

Paano kung mayroon kaming 100,000 buong node na lahat ay tumatakbo nang mas mura, may mataas na kapasidad na mga spinning disk at kahit papaano ay nakumbinsi namin silang lahat na tanggapin ang mga koneksyon ng kliyente ng SPV? Paano kung nagawa rin naming baguhin ang buong node software upang suportahan ang 1,000 konektadong SPV client?

Iyon ay magbibigay sa amin ng 100 milyong socket na magagamit para sa mga kliyente ng SPV na maaaring suportahan ang 25 milyong magkasabay na mga kliyente ng SPV sa network. Kaya ang bawat kliyente ng SPV ay magkakaroon ng 2,160 segundo bawat araw upang mag-sync sa network. Para sa isang buong node na KEEP sa demand, kakailanganin nitong mapanatili ang pare-parehong bilis ng pagbasa na 231MB/s bawat SPV client, na magreresulta sa 231GB/s kung ipagpalagay na 1,000 konektadong SPV client.

Ang isang 7,200 RPM hard drive ay maaaring magbasa ng humigit-kumulang 220MB/s, kaya maaari mong makamit ang read throughput na ito gamit ang isang RAID 0 array ng BIT higit sa 1,000 drive.

Sa oras ng pagsulat maaari kang bumili ng a 10TB drive para sa $400, sa gayon ang $400,000 na hanay ng RAID ng mga drive na ito ay magbibigay-daan sa iyo na mag-imbak ng 20 araw na halaga ng mga bloke - ito ay nagkakahalaga ng mas mapapamahalaang $7.2 milyon upang mag-imbak ng isang taon na halaga ng mga bloke habang nakakamit pa rin ang mga kinakailangan sa disk read throughput.

Ito ay nagkakahalaga ng pagpuna na walang ONE sa kanilang tamang pag-iisip ang magpapatakbo ng isang RAID 0 array na may ganitong maraming drive dahil ang isang solong drive failure ay makakasira sa buong hanay ng mga disk. Kaya ang isang RAID array na may fault tolerance ay magiging mas mahal at hindi gaanong gumaganap. Mukhang hindi kapani-paniwalang optimistiko na ang 100,000 organisasyon ay handang mag-pony up ng milyun-milyong dolyar bawat taon upang magpatakbo ng isang buong node.

Ang isa pang punto na dapat tandaan ay ang mga konserbatibong pagtatantya na ito ay ipinapalagay din na ang mga kliyente ng SPV ay sa paanuman ay mag-coordinate upang ipamahagi ang kanilang mga oras ng pag-sync nang pantay-pantay sa bawat araw. Sa katotohanan, magkakaroon ng pang-araw-araw at lingguhang cyclical na mga peak at mga labangan ng aktibidad - ang network ay kailangang magkaroon ng mas mataas na kapasidad kaysa sa tinantyang nasa itaas para ma-accommodate ang pinakamataas na demand.

Kung hindi, maraming mga kliyente ng SPV ang mabibigo na mag-sync sa mga oras ng peak na paggamit.

Kapansin-pansin, lumalabas na ang pagpapalit ng bilang ng mga socket bawat node ay T makakaapekto sa kabuuang pag-load sa anumang ibinigay na buong node – kailangan pa rin nitong iproseso ang parehong dami ng data. Ang talagang mahalaga sa equation na ito ay ang ratio ng buong node sa mga kliyente ng SPV. At, siyempre, ang laki ng mga bloke sa chain na kailangang iproseso ng buong node.

Ang resulta ay mukhang hindi matatakasan: ang halaga ng pagpapatakbo ng isang buong node na may kakayahang pagsilbihan ang pangangailangan ng SPV ng isang bilyong pang-araw-araw na on-chain na mga transactor ay magiging astronomical.

Naghahanap ng gitnang lupa

Sa puntong ito, medyo malinaw na na ang isang bilyong transaksyon bawat araw ay naglalagay ng gastos sa pagpapatakbo ng isang ganap na pagpapatunay na node sa labas ng maaabot ng lahat maliban sa pinakamayayamang entity.

Ngunit, paano kung i-flip natin ang kalkulasyong ito sa ulo nito at sa halip ay subukang maghanap ng formula para sa pagtukoy sa halaga ng pagdaragdag ng load sa network sa pamamagitan ng pagtaas ng on-chain transaction throughput?

Upang masuportahan ng network ng Bitcoin ang isang target na bilang ng mga transaksyon sa bawat segundo (pagdaragdag ng kapasidad para sa 86,400 net bagong araw-araw na user), maaari naming kalkulahin ang mga kinakailangan sa throughput ng bawat node disk bilang:

Nagbibigay ito sa amin ng pinakamababang disk read throughput bawat segundo para sa isang buong node sa demand ng serbisyo mula sa mga kliyente ng SPV. Gamit ang mga umiiral na katangian ng network at magagamit Technology, maaari naming i-extrapolate ang isang tinantyang halaga ng pagpapatakbo ng node sa pamamagitan ng paggamit ng disk throughput bilang ang ipinapalagay na bottleneck. Tandaan na tiyak na may iba pang mga hadlang sa mapagkukunan na darating, kaya tumataas ang gastos ng buong operasyon ng node.

Para sa sumusunod na mga kalkulasyon, ginamit ko ang mga pagpapalagay na ito:

– Average na laki ng transaksyon sa bytes = 500 bytes batay sa statoshi.info.

– Kabuuang bilang ng mga gumagamit ng SPV = ONE bawat transaksyon bawat araw.

– Mga socket na nakonsumo ng isang SPV client = pamantayan ng apat.

– Bilang ng mga socket na magagamit para sa mga kliyente ng SPV sa bawat buong node = naunang nakalkulang bilang ng 20.

– Kabuuang mga socket ng network na magagamit para sa mga kliyente ng SPV = naunang nakalkulang bilang na 136,000.

– Halaga ng hard drive throughput at space = $400 10TB 7,200 RPM drive sa RAID 0 configuration.

Sa kasamaang palad, ang mga kinakailangan sa disk throughput at sa gayon ang gastos upang mapatakbo ang isang buong node ay tumaas nang quadratically kaugnay sa bilang ng mga transaksyon sa bawat segundo. Ang mga gastos ay mabilis na nagiging hindi maasahan para sa karamihan ng mga entity.

Para sa sanggunian, tandaan na ang Visa ay nagpoproseso ng humigit-kumulang 2,000 mga transaksyon sa bawat segundo. Sa Bitcoin ito ay mangangailangan ng halos $200,000 na halaga ng mga disk para lang KEEP sa pangangailangan ng SPV. Ang ONE puntong dapat tandaan ay KEEP ng mga chart na ito ang bilang ng mga buong node na pare-pareho sa 8,000 - sa katotohanan, malamang na bababa ang mga ito habang tumataas ang gastos, kaya tumaas ang mga kinakailangan sa throughput at gastos ng pagpapatakbo ng natitirang mga node upang mas mabilis na tumaas.

Lumilitaw na ito ay isang pinagsama-samang puwersa ng sentralisasyon ng node.

Ang (hindi makaagham) na mga botohan na pinatakbo ko noong nakaraang taon ay nagpakita na 98% ng mga operator ng node ay hindi magbabayad ng higit sa $100 bawat buwan upang magpatakbo ng isang node, kahit na sila ay lubos na namuhunan sa Bitcoin. Handa akong tumaya na ang pagtaas ng on-chain na mga transaksyon ng bitcoin sa pamamagitan ng isang order ng magnitude ay magreresulta sa pagkawala ng karamihan ng buong node, habang ang pagtaas ng dalawang order ng magnitude ay magreresulta sa pagkawala ng 90% o higit pang mga node.

Naniniwala ako na ligtas na ipagpalagay na napakakaunting mga entity ang handang gumawa ng problema sa pagbuo ng mga RAID array upang magpatakbo ng isang buong node. Kung ito ang sitwasyon, hindi mapagkakatiwalaan na i-claim na ang mga naturang pagtaas ay magiging mainam para sa karaniwang user, dahil T magkakaroon ng halos sapat na full node disk throughput o mga socket na magagamit para sa serbisyo ng SPV demand.

Iba pang mga kahinaan ng SPV

Mahusay ang SPV para sa mga end user na T nangangailangan ng seguridad o Privacy ng isang ganap na nagpapatunay na node. Gayunpaman, maraming mga dahilan na maaaring ituring na mga showstoppers para sa karamihan sa SPV Bitcoin network, anuman ang scalability nito.

Ang SPV ay gumagawa ng mga pangunahing pagpapalagay na nagreresulta sa pagkakaroon nito ng mas mahinang seguridad at Privacy kaysa sa isang ganap na nagpapatunay na node:

• Ang mga kliyente ng SPV ay nagtitiwala sa mga minero upang wastong patunayan at ipatupad ang mga patakaran ng Bitcoin; ipinapalagay nila na ang blockchain na may pinakamalaking pinagsama-samang proof-of-work ay isa ring valid na chain. Maaari mong Learn ang tungkol sa pagkakaiba sa pagitan ng SPV at full node na mga modelo ng seguridad sa artikulong ito.
• Ipinapalagay ng mga kliyente ng SPV na ang buong node ay hindi magsisinungaling sa kanila sa pamamagitan ng pagtanggal. Ang isang buong node ay T maaaring magsinungaling at sabihin na ang isang transaksyon ay umiral sa isang bloke noong T ito aktwal na umiiral, ngunit maaari itong magsinungaling sa pamamagitan ng pagsasabi na ang isang transaksyon na umiiral sa isang bloke ay hindi nangyari.
• Dahil ang mga kliyente ng SPV ay nagsusumikap para sa kahusayan, Request lamang sila ng data para sa mga transaksyong pagmamay-ari nila. Nagreresulta ito sa napakalaking pagkawala ng Privacy.

Kapansin-pansin, ang co-author ng BIP 37 na si Matt Corallo, pinagsisisihan ang paglikha nito:

"Ang isang malaking isyu ngayon para sa Privacy ng mga user sa system ay BIP37 SPV bloom filters. Paumanhin, sinulat ko iyon."

BIP 37 Bloom-filtered SPV clients mayroon karaniwang walang Privacy, kahit na gumagamit ng hindi makatwirang mataas na mga rate ng false-positive. Nalaman ni Jonas Nick [isang security engineer sa Blockstream] na kapag ibinigay ang isang pampublikong key, maaari niyang matukoy ang 70% ng iba pang mga address na kabilang sa isang ibinigay na wallet.

[embed]https://www.youtube.com/watch?v=HScK4pkDNds[/embed]

Maaari mong ayusin ang mahinang Privacy ng SPV sa pamamagitan ng paghahati ng mga filter ng Bloom sa maraming mga kapantay, kahit na ito ay magpapalala sa scalability ng SPV sa pamamagitan ng paglalagay ng mas maraming load sa mas maraming mga full node.

Ang BIP 37 ay mahina din sa mga walang kabuluhang pag-atake sa pagtanggi sa serbisyo. Ang code ng demonstrasyon ay magagamit dito na kayang pilayan ang buong node sa pamamagitan ng paggawa ng maraming mabilis na kahilingan sa imbentaryo sa pamamagitan ng mga espesyal na ginawang filter na nagdudulot ng patuloy na paghahanap ng disk at mataas na paggamit ng CPU.

Ang may-akda ng proof-of-concept ng pag-atake, ang CORE Developer na si Peter Todd, ay nagpapaliwanag:

"Ang pangunahing isyu ay na maaari mong kumonsumo ng isang hindi katimbang na halaga ng disk I/O bandwidth na may napakakaunting bandwidth ng network."

Kahit hanggang ngayon, ang mga alerto sa pandaraya na inilarawan ni Satoshi sa puting papel ay hindi pa ipinatupad. Sa katunayan, ipinakita ng mga pagsisikap sa pagsasaliksik sa lugar na ito na maaaring hindi posible na ipatupad ang mga alerto sa pandaraya.

Halimbawa, gagana lang ang alerto sa pandaraya kung talagang makukuha mo ang data na kinakailangan upang patunayan ang panloloko – kung hindi ibibigay ng minero ang data na iyon, T magagawa ang alerto sa pandaraya. Dahil dito, ang mga kliyente ng SPV ay T antas ng seguridad na naisip ni Satoshi na magkakaroon sila.

Mula sa isang napakataas na antas ng pananaw, ang isang mundo na karamihan ay binubuo ng mga SPV node ay gumagawa ng mga pagbabagong pinagkasunduan gaya ng kabuuang cap ng coin o kahit na ang pag-edit ng ledger. Ang mas kaunting ganap na pag-validate na mga node ay nangangahulugan ng mas sentralisadong pagpapatupad ng mga panuntunan ng pinagkasunduan at sa gayon ay mas kaunting pagtutol sa pagbabago ng mga panuntunan ng pinagkasunduan. Ang ilang mga tao ay maaaring isaalang-alang na isang tampok; tiyak na itinuturing itong isang kapintasan.

Mga potensyal na pagpapabuti

Ang seguridad at scalability ng SPV ay posibleng mapahusay sa maraming paraan sa pamamagitan ng mga patunay ng pandaraya, mga pahiwatig ng pandaraya, mga patunay ng input, mga patunay sa paggastos, at iba pa. Ngunit sa pagkakaalam ko wala sa mga ito ang lumampas sa yugto ng konsepto, mas hindi handa para sa pag-deploy ng produksyon.

Bloom filter na mga pangako

maaaring mapabuti ang Privacy, ngunit mayroong isang tradeoff para sa pagiging kapaki-pakinabang sa pagitan ng laki ng filter at ng maling positibong rate nito: masyadong magaspang ay nangangahulugan na ang mga kapantay ay nagda-download ng napakaraming false-positive na mga bloke, masyadong pino ay nangangahulugan na ang mga filter ay ganap na napakalaki at hindi praktikal para sa sinumang mag-download gamit ang isang SPV client.

Mababawasan nito ang pag-load sa full-node disk throughput, ngunit ang trade-off ay tataas ng bandwidth ng parehong mga kliyente ng SPV at mga full node dahil ang buong mga bloke ay kailangang ilipat sa buong network.

Ito kamakailang iminungkahing compact client-side filtering nag-aalis ng mga isyu sa Privacy , ngunit nangangailangan ito ng buong mga bloke upang ma-download kung may tugma laban sa filter (bagaman hindi kinakailangan sa pamamagitan ng p2p network!).

Mga pangako ng UTXO

maaaring paganahin ang mga kliyente ng SPV na i-sync ang kanilang kasalukuyang set ng UTXO at sa gayon ay balanse ng wallet nang hindi nangangailangan ng buong node upang i-scan ang buong blockchain. Sa halip, magbibigay ito ng patunay ng umiiral na mga UTXO.

Posibleng mag-ingat laban sa mga pag-atake ng DoS na filter ng Bloom sa pamamagitan ng pag-aatas sa mga kliyente ng SPV na magsumite ng proof-of-work (hindi maaring magamit sa isang device na pinapagana ng baterya tulad ng isang telepono) o mga micropayment na nakabatay sa channel (imposibleng mag-bootstrap kung ang isang kliyente ay T pa nakakatanggap ng pera), ngunit walang nag-aalok ng direktang solusyon.

Ang mga kinakailangan sa disk read para sa buong node ay malamang na mabawasan sa maraming paraan sa pamamagitan ng pinahusay na pag-index ng data at batched processing ng mga kahilingan mula sa mga kliyente ng SPV.

Itinuro ni Ryan X Charles sa mga komento sa ibaba na ang paggamit ng protocol sa pagbabayad ng BIP70 upang direktang sabihin sa isang tao ang UTXO ID ng pagbabayad na ipinapadala mo sa kanila ay mag-aalis ng pangangailangan para sa kanila na gumamit ng mga filter ng bloom dahil maaari silang direktang Request ng data mula sa mga buong node. Ito ay hindi kapani-paniwalang mahusay kung handa kang tanggapin ang trade-off sa Privacy .

Sapat na upang sabihin, maraming puwang para sa pagpapabuti - maraming hamon ang kailangang lagpasan upang mapahusay ang on-chain scalability.

Angkop na mga solusyon sa scaling

Kung ipagwawalang-bahala natin ang maraming iba't ibang isyu sa pag-scale sa mas malalaking sukat ng block tulad ng block propagation latency, UTXO set scaling, mga paunang oras ng pag-sync ng blockchain at mga trade-off sa seguridad at Privacy , maaaring teknikal na posible na i-scale ang Bitcoin sa isang bilyong pang-araw-araw na on-chain na user kung may mga entity na handang mamuhunan ng makabuluhang mga mapagkukunan upang bumuo ng mga pagpapahusay ng software at upang mapatakbo ang kinakailangang imprastraktura.

Mukhang hindi malamang na mag-evolve ang Bitcoin sa ganoong paraan, gayunpaman, dahil may mas mahusay na mga paraan upang sukatin ang system. Ang pinaka-epektibo ay isang paraan ng scaling na ginagamit na: pagsasama-sama sa paligid ng mga sentralisadong provider ng API. May posibilidad na magkaroon ng malaking tiwala at Privacy trade-off kapag ginagamit ang mga pamamaraang ito, ngunit marami sa gayong mga pakikipag-ugnayan ang nagsasangkot ng mga kontraktwal na kasunduan na nagpapagaan sa ilan sa mga panganib.

Sa mga tuntunin ng pag-scale sa paraang walang tiwala, ang mga protocol ng Layer 2 gaya ng Lightning ay nag-aalok ng mas mahusay na pag-scale dahil ang mataas na volume ng data na inililipat ay ipinapadala lamang sa maliit na bilang ng mga partidong direktang kasangkot sa isang ibinigay na off-chain na transaksyon. Maaari mong isipin ito bilang pagkakaiba sa pagitan ng broadcast-to-all na layer ng komunikasyon sa ethernet kumpara sa isang naka-ruta na layer ng IP – T masusukat ng internet nang walang pagruruta at gayundin ang Internet of Money.

Bagama't ang diskarteng ito sa scaling ay mas kumplikado sa teknikal kaysa sa tradisyunal na sentralisadong scaling at mangangailangan ng pagtagumpayan ng ilang natatanging hamon, ang up-front investment ng mga mapagkukunan para sa pananaliksik at pagpapaunlad ng mga routing protocol na ito ay magbabayad ng malaking dibidendo sa mahabang panahon, dahil binabawasan ng mga ito ang load na kailangang pasanin ng buong network sa pamamagitan ng mga order ng magnitude.

Mayroon ding maraming mga pagpipilian sa pagitan na maaaring tuklasin:

– Mga sentralisadong custodial scheme na may perpektong Privacy na gumagamit ng mga token ng Chaum gaya ng HashCash.

– Sentralisadong non-custodial zero knowledge proof system tulad ng TumbleBit.

– Federated (semi-trusted multisignature) sidechainshttps://elementsproject.org/sidechains/.

– Miner-secured (semi-pinagkakatiwalaan) mga drivechain.

ako ay kumbinsido pa rin na sa mahabang panahon, ang Bitcoin ay mangangailangan ng mas malalaking bloke.

Ngunit maging matiyaga at mataktika tayo sa pamamagitan ng pagsisikap na sukatin ang system nang mahusay hangga't maaari habang pinapanatili ang mga katangian ng seguridad at Privacy nito.

Ang isang auditable, bahagyang desentralisadong PayPal ay tiyak na magkakaroon ng utility kung ito ay gumagana mula sa pananaw ng karaniwang gumagamit, ngunit hindi ito mag-aalok ng antas ng pinansiyal na soberanya na tinatamasa ng mga bitcoiner ngayon.

Salamat kina Matt Corallo, Mark Erhardt at Peter Todd sa pagsusuri at pagbibigay ng feedback para sa artikulong ito

Disclosure: Ang CoinDesk ay isang subsidiary ng Digital Currency Group, na mayroong stake ng pagmamay-ari sa Blockstream.