Lightning's Balancing Act: Mga Hamon na Hinaharap sa Scalability Savior ng Bitcoin

Si Jameson Lopp ay isang software engineer sa BitGo, tagalikha ng Statoshi.info at tagapagtatag ng Bitcoinsig.com. Nasisiyahan siya sa pagbuo ng mga serbisyo sa web at naiintriga siya sa mga problema ng sukat.

Sa feature na ito, sinusuri ng Lopp ang Lightning Network, isang iminungkahing solusyon para sa pag-scale ng Bitcoin network at pagpapagana ng mga murang microtransactions, pag-aaral sa mga potensyal na nakakatakot na hamon sa inisyatiba.

Ang komunidad ng Bitcoin ay tinatalakay ang konsepto ng Lightning Network sa loob ng isang taon. Madalas itong binabanggit sa mga debate sa scalability bilang solusyon sa limitadong kakayahan ng throughput ng transaksyon ng bitcoin.

Gayunpaman, ito ay isang kumplikadong konsepto at ilang bahagi ng pagpapatupad ay teoretikal pa rin o nasa pagbuo.

Susubukan ng artikulong ito na magbigay ng higit pang insight sa kung paano gagana ang Lightning Network at ang mga hamong haharapin nito. Ipinapalagay ng mga sumusunod na mayroon kang pangunahing pag-unawa sa Network ng Kidlat. Kung bago ka sa konseptong ito, maaari mong tingnan ang paliwanag na ito sa mga tuntunin ng karaniwang tao o basahin ang mga teknikal na detalye dito.

Dahil ang Lightning protocol ay nasa pagbabago, ang ilan sa aking mga konklusyon ay maaaring hindi wasto o maaaring hindi wasto sa NEAR hinaharap. Iba't ibang modelo at simulation ang ipapakita sa kabuuan ng artikulong ito, ngunit walang garantiya na magiging totoo ang alinman sa mga ito - walang halaga ng theorizing ang maaaring palitan ng real-world na data kapag gumagana na ang network. Sa kasalukuyan ay may apat na magkakaibang proyekto (Kidlat, Blockstream, Eclair at Thunder Network) nagtatrabaho sa code para sa mga katugmang pagpapatupad, ngunit T namin inaasahan ang isang minimum na mabubuhay na protocol hanggang sa tag-araw sa pinakamaagang panahon.

Gusto ng ilang tao na tawagan ang Lightning Network bilang isang caching layer, ngunit maaaring mas tumpak na isipin ito bilang isang settlement deferral system. Kung napagtanto mo na ang isang malusog na ekonomiya ay may halaga na patuloy na dumadaloy pabalik- FORTH sa gitna ng mga kalahok (node) sa ekonomiya, makikita mo na marami sa mga paglilipat ng halaga ay talagang kakanselahin at ang netong pagbabago sa pamamahagi ng halaga sa paligid ng economic network ay magiging mas maliit kaysa sa kabuuang halaga na natransaksyon.

Upang magtagumpay ang Lightning Network, kakailanganin nitong gamitin ang economic property na ito – ngunit T ito magiging simple.

Bilang isang software engineer para sa isang Bitcoin wallet, ako ay nabighani sa mga teorya at mungkahi upang mapabuti ang sistema. Sa sandaling malinaw na ang isang panukala ay patungo na sa katotohanan, ang mga detalye ng pagpapatupad ay nagiging mas mahalaga.

Matapos gumugol ng hindi mabilang na oras sa pagbabasa ng lahat ng impormasyong magagamit tungkol sa Lightning Network, masaya akong iulat na ang mga teoretikal na kakayahan nito ay lubos na nakakumbinsi.

Gayunpaman, ang scalability na walang kakayahang magamit ay hahadlang sa amin na baguhin ang teoretikal sa kongkreto.

Mga kumplikadong macro

Bagama't ang puting papel ng Lightning Network ay medyo malinaw tungkol sa kung paano gagana ang mga channel ng pagbabayad ng Lightning, mayroon pa ring maraming mga katanungan tungkol sa kung paano gagana ang network sa kabuuan.

ONE sa mga pinakamalaking hindi kilalang tanong ay kung ano ang magiging hitsura The Graph ng Lightning Network.

Upang maging mas espesipiko: Ano ang magiging proporsyon ng lubos na konektadong mga node sa mga kakaunting konektadong node? Ang isang network na may karamihan sa mga node na mahusay na konektado ay magiging mas siksik at magbibigay-daan sa pagtawid The Graph na may mas kaunting hops, na magiging mas mahusay.

Ang isang network na may kakaunting "hub" na node lang ay higit na magkakahiwalay, na nangangailangan ng mga user na pumili ng mas mahaba, hindi gaanong mahusay na mga ruta sa pamamagitan ng network o piliin na dumaan sa ilang well connected node. Kung ang mga user ay na-incentivize na gumamit ng ilang well-connected na node para sa pagruruta ng pagbabayad, ito ay nagdudulot ng mga isyu sa Privacy at lumilikha ng mas malaking target para sa mga umaatake na guluhin ang network.

Narito ang isang simpleng halimbawa ng mga potensyal na graph na maaaring mabuo ng Lightning Network node, sa kagandahang-loob ng Paige sa MaidSafe.

Pinaghihinalaan ko na ang hugis ng network ay magiging katulad ng pangalawang graph, na may ilang kapansin-pansing mahusay na konektadong mga node.

Ito ay batay sa pagsusuri ng FLOW ng pera sa loob ng Bitcoin network noong 2012 na mababasa mo sa papel "Isang Fistful of Bitcoins: Pagkilala sa mga Pagbabayad sa Mga Lalaking Walang Pangalan."

Habang ang pang-ekonomiyang network ng bitcoin ay malinaw na mas malaki at mas kumplikado ngayon kaysa noong 2012, ang mga relasyon sa pagitan ng mga kalahok ay malamang na magkatulad pa rin.

Ang mga insentibo ba ng network ay magreresulta sa sentralisasyon sa paligid ng medyo maliit na bilang ng mataas na konektadong mga node?

Maaari naming mahulaan ang ilan sa mga dynamics ng Lightning Network sa pamamagitan ng pagsusuri Bose-Einstein Condensation sa Complex Networks.

Ang buod ay ito: Sa mga network kung saan ang mga node ay nakikipagkumpitensya para sa pagiging pinakamahusay na konektado dahil nagbibigay ito sa kanila ng isang kalamangan sa iba pang mga node, ang mga phenomena tulad ng "first-mover-advantage," "fit-get-rich," at "winner-takes-all" ay nagreresulta sa sentralisasyon ng network bilang isang minorya ng mga node sa kalaunan ay nakakuha ng malaking bahagi ng mga link ng network.

Pinatakbo ni Anthony Towns ang simulation sa itaas ng isang simpleng Lightning Network na nagpapakita kung paano maaaring maging concentrate ang value sa mga routing node sa mas mahabang panahon.

Mukhang may insentibo, kahit man lang para sa pagruruta ng mga node, na maging maayos na konektado sa iba pang mga node hangga't maaari upang mairuta mo ang pinakamaraming trapiko at sa gayon ay makuha ang pinakamaraming bayarin. Sa kabilang banda, may disincentive na magpatakbo ng isang sikat na routing node dahil mangangailangan ito ng malaking halaga ng bitcoins para ma-lock up sa mga tuntunin ng liquidity at malantad pa sa mga tuntunin ng pribadong key security.

Ito ay nananatiling upang makita kung saan ang ekwilibriyo ay manirahan sa pagitan ng mga magkasalungat na dinamika.

Mukhang malamang na magpapakita ang Lightning ng power law distribution ng node connectivity na magbibigay dito ng mga katangian ng network na walang sukat.

Ito ay maaaring magbigay sa amin ng ilang insight sa katatagan ng network sa pagkabigo. Sa isang network na walang sukat, ang mga node na may pinakamainam na koneksyon ay konektado sa mga node na hindi gaanong mahusay na konektado, at pagkatapos ay konektado ang mga node na ito sa iba pang mga node na may mas kaunting koneksyon, at iba pa.

Ang hierarchy na ito ay nagbibigay-daan sa isang antas ng fault tolerance.

Kung ang mga pagkabigo ay nangyayari nang random at ang karamihan sa mga node ay ang mga may mababang koneksyon, ang posibilidad na ang isang mataas na konektadong node ay maaapektuhan ay bale-wala. Kahit na nabigo ang isang mataas na konektadong node, ang network sa pangkalahatan ay hindi mabali dahil sa natitirang lubos na konektadong mga node.

Sa kabilang banda, kung maraming mataas na konektadong mga node ang nabigo nang sabay-sabay, ang network ay maaaring mabali sa mga nakahiwalay na mga graph. Kaya, ang Lightning Network ay maaaring magkaroon ng ilang sentralisasyon sa paligid ng mataas na konektadong mga node habang nagpaparaya pa rin sa bahagyang pagbagsak ng network

Ang isa pang dahilan kung bakit mahalaga ang hugis ng network ay posibleng maging hindi balanse ang network.

Tulad ng nabanggit kanina, sinasamantala ng Lightning Network ang katotohanan na ang paglipat ng netong halaga sa paligid ng isang pang-ekonomiyang network ay napakaliit kumpara sa kabuuang dami. Isipin kung ano ang mangyayari kung maraming halaga ang dumadaloy sa isang lugar na hindi gaanong konektado sa network (isang "gilid" sa graph ng network) - wala na itong mapupuntahan.

Ito ay maaaring mangyari kung ang isang serbisyo ay nakakaranas ng pagtaas ng katanyagan, tulad ng kung ito ay naglalabas ng isang bagong tampok na pamatay o nag-anunsyo ng isang firesale. Kung ang isang baha ng halaga ay ipinadala sa kanila, kung gayon maaari nitong mawalan ng balanse ang marami sa mga channel sa kalapit na paligid, na mapipilitang magtaas ng mga bayarin nang malaki o magsara.

Kung ang hugis ng network ay makatwirang desentralisado, kung gayon ang natitirang bahagi ng network ay mananatiling hindi maaapektuhan ng mga pagsasara ng mass channel.

Gayunpaman, kung mas mukhang hub ito at hugis spoke, maaaring maabala nang husto ang network. Ang mga malawakang pagsasara ng channel sa mga panahon ng mababang on-chain na pagtatalo ay malamang na T magiging malaking bagay dahil ang mga node ay maaari lamang muling magtatag ng isang saradong channel sa pagbabayad na may parehong on-chain na transaksyon na magsasara nito.

Magiging mas problema ang sitwasyong ito sa mga panahon ng mataas na pagtatalo para sa mga bloke, na tutuklasin natin sa ibang pagkakataon.

T: Paano gumagana ang Discovery ng landas sa Lightning Network?



A: T namin alam. Ito ay isang mahirap na problema.#ScalingBitcoin







— Jameson Lopp (@lopp) Disyembre 7, 2015

Ang dynamics ng Lightning Network ay magiging mas kumplikado sa pamamagitan ng katotohanan na ang mga paglilipat ng halaga ay hindi palaging dadaan sa pinakamaikling landas sa pagitan ng dalawang node.

Ito ay resulta ng Pagruruta ng sibuyas ipinapatupad dahil sa mga alalahanin sa Privacy . Ang mga detalye kung paano makakahanap ng landas ang isang node upang iruta ang isang pagbabayad sa network ay hindi pa natatapos, kaya mahirap sabihin kung ano ang magiging epekto ng pagruruta sa dynamics ng network.

Mukhang ang paunang plano ay upang ipatupad ang Discovery ng node sa pamamagitan ng mga channel ng IRC - sa parehong paraan na ang mga unang bersyon ng Bitcoin ay nagsagawa ng Discovery ng node . Maaari din nating makita ang mga "beacon node" na ipinatupad na magpapadali sa paghahanap ng landas, at sa mahabang panahon maaari tayong makakita ng mga path na nakaimbak sa isang distributed hash table.

Kung nag-iisip tayo ng masama, maaari nating itanong, 'Maaari bang magbukas ang isang mayamang umaatake ng mga channel na may mataas na kapasidad sa magkabilang dulo ng network at iruta ang malalaking pagbabayad sa network, na hindi balansehin ang maraming channel at pinipilit silang magsara habang nagbabayad ng mga hindi gaanong bayad para isagawa ang pag-atake?'

Ito ay hindi partikular na naiiba kaysa sa isang katulad na pag-atake na maaaring isagawa on-chain na may isang mayamang attacker na pinupunan ang mga bloke, kahit na ito ay maaaring maging mas mura upang isagawa sa Lightning Network.

Ito ay nananatiling upang makita kung gaano katatag ang Lightning Network laban sa pagtanggi sa mga pag-atake ng serbisyo; ito ay depende sa kung gaano kalaki ang liquidity na makukuha mula sa iba pang mga node sa paligid ng isang "value flood" at kung gaano katalino ang mga node tungkol sa pag-adapt sa naturang baha at pagruruta ng halaga sa paligid ng network upang muling balansehin ang mga channel.

Napansin ng developer ng Lightning na si Tadge Dryja na tataas ang mga bayarin nang walang sintomas habang nagiging mas hindi balanse ang mga channel, na nagpapataas ng gastos sa pagruruta sa isang hindi balanseng bahagi ng network, na nagiging sanhi ng pagiging mahal nito para sa isang tao na mapanatili ang isang pag-atake sa pagtanggi sa serbisyo.

Kung ang isang malaking bahagi ng mga node ay nahuhulog sa network, paano gumaling ang network?

Gaya ng nasabi kanina, ito ay pangunahing magiging problema kung mahirap na muling magtatag ng mga channel na may mga on-chain na transaksyon. Ang tanong tungkol sa kalusugan ng network ay nakakalito dahil ginagawa ito ng iba't ibang mga koponan na ngayon ay bumubuo ng mga pagpapatupad ng Lightning Network nang nasa isip ang Privacy .

Bilang resulta, malamang na T posible na sistematikong imapa ang istraktura ng buong network. Kung ganito ang sitwasyon, magiging mahirap ding bumuo ng mga tool na nagbibigay-daan sa amin upang matukoy ang kalusugan ng network sa mga tuntunin ng pagkakakonekta The Graph at mga balanse ng channel. Kaya't maaari lamang nating malaman na ang network ay naaabala kung ang bilang ng mga hop na dadalhin sa isang partikular na node ay biglang tumaas o nagiging imposibleng makahanap ng ruta patungo sa node na iyon.

Ang kakayahan para sa Lightning Network na makabawi mula sa bahagyang pagbagsak ng network (dahil sa channel exhaustion) ay depende sa laki ng network (ang bilang ng mga bukas na channel) na may kaugnayan sa bilang ng mga on-chain na transaksyon na kayang tanggapin ng Bitcoin network.

Ang mas malaki ang Lightning Network ay lumalaki sa mga tuntunin ng bilang ng mga channel, hindi gaanong nababanat ito sa pagkagambala ng network dahil sa mga Events na pumipilit sa pagsasara ng mass channel dahil sa limitadong kapasidad para sa Bitcoin network na suportahan ang muling pagtatatag ng mga channel.

Sa isang sitwasyon kung saan maraming mga node ang napipilitang muling itatag ang mga channel ngunit mataas ang pagharang ng pagtatalo, ang mga channel ay magiging mahalagang walang silbi (unidirectional) hanggang sa makumpirma ang isang on-chain na transaksyon upang muling maitatag ang channel na may balanseng halaga.

Maaaring maipapayo para sa mga kalahok sa network na may maraming liquidity na magpatakbo ng mga node sa iba't ibang bahagi ng network graph para kung magkaroon ng ganoong sitwasyon, maaari nilang iruta ang pera mula sa unidirectional imbalanced na mga channel patungo sa kanilang iba pang node upang muling balansehin ang ilang channel at mabawasan ang pagkaantala.

Kung ang mga cascading channel imbalances ay nag-tutugma sa mataas na pagtatalo para sa block space, mapipilitan kaming harapin ang problema sa mga oras ng lock para sa mga revocation window.

May teorya na kung sakaling magkaroon ng ganap na mga bloke, maaari tayong magdagdag ng lohika upang ang isang "buong bloke" ay T mabibilang sa oras ng pagsasara, ngunit sa oras ng pagsulat ay walang walang palya na paraan upang italaga kung aling mga bloke ang puno. Ang blockstream co-founder at Bitcoin developer na si Greg Maxwell ay nagmungkahi na ang mga minero ay maaaring magtakda ng bandila, ngunit ito ay nangangahulugan na ang mga minero ay sumang-ayon kung paano italaga ang mga bloke bilang puno.

Mukhang hindi malamang na ang naturang watawat ay isang tuntunin ng pinagkasunduan, kaya limitado ang pagiging maaasahan nito.

Ang pag-iingat laban sa mga isyung ito sa mataas na antas ng network ay mangangailangan ng maselang engineering, ngunit walang dahilan upang maniwala na T malulutas ang mga ito.

Mga micro complexity

Malinaw mula sa puting papel na ang napakaraming teorya ng laro ay napupunta sa paggawa ng mga indibidwal na channel ng pagbabayad at pagruruta ng mga pagbabayad sa mga channel na matatag laban sa counterparty na pagnanakaw. Gayunpaman, magkakaroon ng higit pang pagiging kumplikado na kakailanganing pangasiwaan sa indibidwal na antas ng node upang ma-maximize ang pangmatagalang kahusayan ng mga channel na pinapanatili nito.

Ang mga gumagamit ay maaaring makakuha ng isang pagbabalik sa kanilang Bitcoin sa pamamagitan ng pagpapatakbo ng isang mahusay na konektado, maaasahang node at pagruruta ng maraming mga pagbabayad sa pamamagitan nito.

Ito ay malamang na isang malupit na mapagkumpitensyang merkado ng bayad dahil ang mga hadlang sa pagpasok ay kaunti lamang at walang gaanong pagkakaiba ng ONE node mula sa isa pa maliban sa magagamit na pagkatubig at ang bayad na sinisingil. Isipin ito tulad ng pagmimina ng Bitcoin ngunit mas mapagkumpitensya dahil T mo kakailanganin ang custom na hardware o maraming kapangyarihan, isang online na computer lamang at ilang Bitcoin.

Gusto ng mga node na KEEP balanse ang halaga sa mga channel upang maiwasan ang mga ito na maging unidirectional, na nangangailangan ng pagsasara ng channel sa blockchain - isang medyo magastos na operasyon.

Ang pinakamainam na iskedyul ng bayad sa isang lokal at pandaigdigang saklaw ay ONE kung saan ang mga paglilipat na ang mga hindi balanseng channel (humahantong sa isang mas tabing na channel na may ONE partido na mayroong higit sa kalahati ng paglalaan ng channel) ay sinisingil ng mas mataas na bayad kaysa sa mga nakakatulong na balansehin ang isang channel.

Sa katunayan, kung nagpapatakbo ka ng isang routing node at ang ONE o higit pa sa iyong mga channel ay naging hindi balanse sa punto na maaaring kailanganin mo itong isara sa lalong madaling panahon, maaari itong magkaroon ng katuturan sa ekonomiya Para sa ‘Yo na mag-alok ng isang negatibong bayarin sa transaksyon upang iruta ang isang transaksyon na maaaring muling balansehin ang channel, kaya pinipigilan kang magbayad ng mas mahal na on-chain na bayarin sa transaksyon upang isara ang channel.

Maraming literatura at presentasyon tungkol sa Lightning Network ang nagsasabi na ang mga channel na nakabatay sa numero ng pagkakasunud-sunod ay maaaring manatiling bukas nang walang katapusan.

Ito ay totoo sa loob ng konteksto ng isang channel, ngunit malamang na hindi ito totoo sa mas malawak na konteksto ng buong network. Ito ay dahil ang mga bayarin sa pagruruta ay bababa channel sa paglipas ng panahon.

Isipin na nagpapatakbo ka ng isang routing node na may maraming channel na may kabuuang kapasidad na 10 BTC at una mong pinondohan ang mga ito ng 5 BTC ng kabuuang halaga. Kung mangolekta ka ng 0.01% na bayarin sa bawat transaksyon, makakakuha ka ng 5 BTC pagkatapos iruta ang 50,000 BTC at T ka na makakakolekta ng anumang mga bayarin para sa pagruruta ng mga pagbabayad. Maaari mo pa ring iruta ang mga pagbabayad para sa libre o negatibong mga bayarin, ngunit malamang na gusto mong isara ang mga channel at muling itatag ang mga ito upang magpatuloy sa pagkolekta ng mga bayarin.

Mayroon ding mga katanungan tungkol sa pagkatubig na ibinigay na ang mga gumagamit ng Lightning ay kailangang matukoy (at mas mabuti na labis na tantiyahin) ang halaga ng halaga na gusto nilang ilaan sa network.

Ito ay malamang na nakadepende sa isang bilang ng mga variable tulad ng kaso ng paggamit para sa bawat channel, kung ang node ay iruruta ang mga pagbabayad o hindi, at ang haba ng oras na handa ang user na KEEP bukas ang isang channel.

Anthony Towns

hinuhulaan na may makikita tayo sa pagkakasunud-sunod ng:

• $1-$10 para sa mga device ng Internet of Things na nagpapadala ng mga micropayment
• $10-$100 para sa mga router/cloud na computer
• $1,000-$5,000 para sa mga merchant na gumagawa ng makatwirang dami
• $1,000-$100,000 para sa mga node na tumatakbo bilang mga pamumuhunan sa pagbuo ng kita.

Ilang channel ng pagbabayad ang KEEP bukas ng karaniwang user?

Mahirap itong sagutin dahil ideally, ito ay hahawakan sa ilalim ng hood ng wallet software. Sa aking kaalaman, ang lohika sa likod kung paano magpapasya ang mga wallet kung kanino magtatag ng mga channel ay hindi pa na-explore. Para sa kadalian ng paggamit, ito ay mas mabuti na awtomatiko, ngunit pagkatapos ay ang mga wallet ay mangangailangan din ng isang paraan upang makahanap ng mga Lightning node na mayroong mga bitcoin na magagamit upang makapagtatag ng isang bagong channel.

Hindi malamang na makakita tayo ng maraming channel na may mataas na halaga na may kapasidad na higit sa ilang libong dolyar – Ang mga user ng Lightning na may maraming halaga na nakatuon sa network ay ikakalat ang halagang iyon sa maraming channel at posibleng maging sa maraming node upang mapadali ang muling pagbabalanse.

Bagama't bidirectional ang mga channel sa pagbabayad, hindi kinakailangang pondohan ang mga ito sa balanseng paraan kung ang channel ay hindi pinapatakbo ng isang routing node. Ang mga merchant at tagaproseso ng pagbabayad ay maaaring ma-insentibo na magtatag ng maraming mga channel na sa simula ay pinondohan ng ibang mga partido - ang mga channel na ito ay talagang gagamitin lamang para sa pagtanggap ng mga pondo.

Sa kabilang banda, ang mga mamimili ay kadalasang magtatatag ng mga channel na pinondohan lamang ng kanilang mga sarili at pangunahing ginagamit para sa pagpapadala ng mga pondo. Ang mga nagproseso ng pagbabayad gaya ng BitPay ay maaaring magbukas ng maraming channel upang makatanggap ng mga pagbabayad at ilan upang magpadala ng mga bayad sa iba pang mga entity gaya ng mga palitan, ngunit maaari silang mag-opt na huwag iruta ang mga pagbabayad dahil sa mga alalahanin sa AML/KYC.

Ang alinman sa paggamit sa itaas ng network ay magiging suboptimal; parang gusto ng mga developer ng Lightning na i-default ang wallet software sa pagbubukas ng maraming channel at default sa pagruruta ng mga pagbabayad kung maaari, dahil ito ang pinakamainam para sa kalusugan ng network. Napansin ni Tadge Dryja na ang pagpapatupad ng Lightning ay hindi awtomatikong tumutugma sa pagpopondo para sa isang papasok na channel bilang default. Kung walang pakikipagtulungan ng dalawang partido, awtomatikong nagagawa ang mga hindi balanseng channel kapag may ipinadalang bayad.

Magkakaroon din ng mga kawili-wiling dinamika kapag ang isang entity na may maraming bukas na channel ay ONE na ng katapat.

Kapag malapit nang magsara ang isang channel, kakailanganin mong magpasya kung gusto mong:

• Subukang KEEP nasa Lightning Network pa rin ang halaga ng iyong halaga
• Mag-alis hangga't maaari
• KEEP ang iba pang mga channel kung ano-ano.

Kung ang isang counterparty ay nagsasara ng isang channel at mayroon ka pa ring isang patas na halaga sa loob nito na gusto mong panatilihin, maaari mo itong ipadala sa kanila pabalik sa iyong sarili sa ibang channel.

Sa kabilang banda, kung gusto mong isara ang isang channel at ilipat ang mas maraming halaga mula sa Lightning Network hangga't maaari, maaari kang magpadala ng mga pondo mula sa isa pang channel pabalik sa iyong sarili sa channel na iyong isinasara.

Magkakaroon ng insentibo para sa mga operator ng Lightning Network nodes na magpatakbo din ng mga Bitcoin node upang masubaybayan nila ang blockchain para sa pagbawi at pag-sweep ng mga transaksyon. Kung hindi, ang sinumang lumalahok sa isang Lightning Network channel ay nangangasiwa na sila ay dayain ng katapat ng channel.

Siyempre, maaari rin nating makita ang mga tao na gumagamit ng mga serbisyo ng third-party upang pamahalaan ang mga channel ng pagbabayad ng Lightning Network sa kanilang ngalan, na kinabibilangan ng pagpapatakbo ng isang buong node upang subaybayan ang blockchain.

Maaari mong ibigay ang transaksyon sa sweep sa mga third-party na kumpanya at hangga't may mapansin silang malisyosong aktibidad ng iyong katapat at mag-sweep sa ngalan mo, ligtas ka. Maaari mong higit pang bigyan ng insentibo ang ikatlong partido na subaybayan ang blockchain nang matapat sa pamamagitan ng pagdaragdag ng isang output sa transaksyon na nagbabayad ng bayad sa ikatlong partido.

Posible ba para sa mga third party na pamahalaan ang mga channel ng pagbabayad sa isang non-custodial na paraan? Ito ay partikular na nauugnay para sa aking tagapag-empleyo, si BitGo, dahil sinasadya naming iniiwasan ang pagiging kustodian.

Malinaw na magiging simple para sa mga third party na walang pagtitiwalaang subaybayan ang blockchain para sa mga transaksyon sa pangako sa ngalan ng isang gumagamit ng Lightning Network. Mas mainam kung maaari kaming gumamit ng multi-sig upang mapadali ang pag-update ng estado ng isang Lightning channel, kahit na ang mga kinakailangan sa latency ay maaaring magdulot ng karagdagang hamon.

Sa maliwanag na bahagi, ayon sa developer ng Lightning na si Joseph Poon, ito ay sa teoryang posible na magkaroon ng third party na kumilos bilang escrow agent para sa isang Lightning channel.

Paano magpapatakbo ang mga user ng mga channel sa pagbabayad kung hindi sila online 24/7? Maaari kang magkaroon ng channel na nilikha mo para sa mga paminsan-minsang pagbabayad at lumukso lamang online kapag may gusto kang bilhin. Ang mas nakakalito ay kung gusto mong makatanggap ng bayad, kailangan mo ring online.

Nangangahulugan ito na ang isang Lightning node na karaniwang offline ay hindi dapat magtatag ng channel na may node na T palaging online. Ang kawalan ba ng kakayahang makatanggap ng mga pagbabayad habang offline ay magreresulta sa pagpili ng mga user na payagan ang mga tagapag-alaga na magpatakbo ng mga channel para sa kanila? Ito ay nananatiling makikita, kahit na ang kakayahang magpatakbo ng 2-of-3 multisig ay maaaring gawin itong isang ligtas na opsyon.

Bilang sakop sa a nakaraang post, ang halaga ng pagpapatakbo ng Bitcoin node ay lubos na nakakaapekto sa kung gaano karaming mga gumagamit ang nagtatapos sa pagpapasya na magpatakbo ng ONE. Magkakaroon ng maraming kumplikado sa pagpapatakbo ng Lightning node at dapat magsikap ang mga developer na i-abstract ang karamihan sa mga ito hangga't maaari upang ma-maximize ang kadalian ng paggamit at sa gayon ang pamumuhunan sa oras na kasangkot sa pagpapatakbo ng isang node.

Bagong network, bagong dynamics

Sa isang bagong kumplikadong sistema na may sariling dynamics ay darating ang maraming hindi alam, at ang mga tao ay may posibilidad na matakot sa hindi alam. Ang ilan ay nagtalo na ang isang matagumpay na Lightning Network ay magpahina sa Bitcoin network dahil ito ay "magnanakaw" ng mga bayarin mula sa mga minero.

Ang paninindigan na ito ay tila maikli, gayunpaman, dahil kung pinahihintulutan ng Lightning Network ang isang user na bawasan ang kanilang mga on-chain na transaksyon sa pamamagitan ng isang factor na X, kung gayon ay makatuwirang pang-ekonomiya para sa isang user na handang magbayad ng anumang bayad na mas mababa sa AVERAGE_BITCOIN_FEE * X - AVERAGE_LIGHTNING_FEE * X.

Gayundin, ang mga bayarin sa Lightning Network ay "bumababa" sa mga bayarin sa Bitcoin . Gaya ng nabanggit kanina, ang mga bayarin na kinokolekta ng mga Lightning node na nagruruta ng mga pagbabayad ay magpapababa sa halaga ng magagamit na halaga na iruruta sa channel hanggang sa ito ay maubos at dapat na sarado.

Ang node ay kailangang magbayad ng Bitcoin fee para magawa ito, kahit na ginagamit nila ang on-chain na transaksyon upang muling magtatag ng channel na may mga kita mula sa mga bayarin na muling namuhunan pabalik sa Lightning Network. Pagkatapos kung ang node ay nagpasya na gastusin ang mga kita sa Lightning Network, ito ay bubuo ng mga bayarin sa Lightning sa iba pang mga node na kalaunan ay tumutulo sa mga bayarin sa Bitcoin kapag ang mga channel na iyon ay sarado.

Sa wakas, ang isang matagumpay na Lightning Network ay magbibigay-daan sa ganap na bagong mga kaso ng paggamit na hindi posible on-chain, na magdadala ng higit pang pang-ekonomiyang aktibidad (at mga bayarin sa pagmimina) sa Bitcoin habang ang mga gumagamit ay nagbubukas at nagsasara ng mga channel.

Ang isang kawili-wiling resulta ng pag-asa ng Lightning sa mga on-chain na transaksyon ay ang isang napakasikat na Lightning Network ay maaaring lumikha ng mas maraming demand para sa mga on-chain na transaksyon kaysa sa pag-offload nito, na lubhang tumataas ang mga on-chain na bayarin na handang bayaran ng mga user.

Sa kasalukuyan, mapoprotektahan ng mga gumagamit ng Bitcoin ang kanilang sarili mula sa pagkasumpungin ng exchange rate sa pamamagitan ng pagbili kaagad bago magpadala ng bayad at maaaring magbenta ang isang merchant o tagaproseso ng pagbabayad sa ilang sandali matapos itong matanggap.

Sa Lightning Network, ang mga user at tagaproseso ng pagbabayad ay kailangang humawak ng mga bitcoin sa loob ng ilang linggo o buwan. Malamang na makikita natin ang mga palitan na nag-aalok ng mga Lightning na deposito upang mapadali ang malapit-instant na conversion. Ang isa pang potensyal na solusyon ay atomic cross-chain swaps sa isang fiat-based na Crypto asset.

Nauna naming nabanggit ang problema sa pagkatubig ng pangangailangang i-lock ang mga bitcoin sa isang channel para sa isang hindi tiyak na tagal ng panahon. Paano kung kailangan mong gumawa ng on-chain na pagbabayad, ngunit ang lahat ng iyong mga barya ay naka-lock sa Lightning Network at T mo gustong isara ang iyong mga channel? Malamang na makakita tayo ng mga taong nag-aalok ng mga serbisyo sa labas ng ramp upang malutas ang problemang ito.

Maaari kang magpadala ng Lightning payment sa serbisyo X at gagawa sila ng on-chain na transaksyon sa Bitcoin sa ngalan mo.

Maaari din nating makita ang "mga serbisyo ng tagapagbigay ng likido" na lumitaw, malamang na pinapatakbo din ng mga palitan. Kung, halimbawa, mayroon kang bukas na Lightning channel na naging hindi balanse, maaari kang magpadala ng pera out-of-band (gaya ng sa pamamagitan ng ACH transfer) sa isang liquidity provider at iruruta nila ang halaga sa iyo sa Lightning Network upang muling balansehin ang channel.

Maaari nitong mailigtas ang mga tao sa abala sa paggawa ng maraming on-chain na transaksyon upang isara at muling buksan ang kanilang mga channel, bagama't kabilang dito ang pagtitiwala sa isang third party na ipadala ang mga pondo sa Lightning Network. Sa katunayan, ang mga tagapagbigay ng pagkatubig na ito ay maaaring maging mahalaga sa pagpapanatili ng mga balanseng channel sa mahabang panahon, ayon sa mga karagdagang simulation na isinagawa ng Anthony Towns.

Sa bawat isa sa mga sumusunod na simulation mayroon kaming apat na tao (A/B/C/D) na bawat isa ay bumibili ng kape bawat araw mula sa isang random na barista (E/F/G/H) sa pamamagitan ng Lightning. Sa unang simulation, ang mga routing node ay kulang sa pondo, ang A/B/C/D ay walang natanggap na kita sa pamamagitan ng Lightning, at ang E/F/G/H ay walang mga gastos na maaari nilang bayaran sa pamamagitan ng Lightning.

Bilang resulta, humihinto ang aktibidad ng network kapag naging hindi balanse ang mga routing node.

Sa pangalawang simulation, ang mga routing node ay sapat na pinondohan, ang A/B/C/D ay walang natanggap na kita sa pamamagitan ng Lightning, at ang E/F/G/H ay walang mga gastos na maaari nilang bayaran sa pamamagitan ng Lightning.

Bilang resulta, huminto ang aktibidad ng network kapag nasira ang A/B/C/D at puno ang mga wallet ng E/F/G/H.

Sa ikatlong simulation, ang mga routing node ay sapat na pinondohan, ang A/B/C/D ay walang natanggap na kita sa pamamagitan ng Lightning, at ang E/F/G/H ay walang mga gastos na maaari nilang bayaran sa pamamagitan ng Lightning.

Gayunpaman, idinagdag ang isang exchange (node ​​X), at ang A/B/C/D ay nagbebenta ng fiat para sa mas maraming lightning fund kapag malapit nang masira, habang ang E/F/G/H ay nagbebenta ng lightning fund para sa fiat kapag ang kanilang mga channel ay naging hindi balanse sa kanilang direksyon.

Ang pagkakaroon ng fiat exchange ay tila ang pinakanapapanatiling paraan upang paganahin ang muling pagbabalanse ng channel sa pamamagitan ng pagpayag sa kita na pumasok at lumabas sa Lightning Network.

Sa teorya, ang isang kumplikadong closed system (ang mga barista ay bumibili ng mga butil ng kape mula sa isang tao, na bibili ng kagamitan sa pagsasaka mula sa ibang tao, na bibili ng mga kagamitan sa hardware mula sa ONE sa mga taong umiinom ng kape) ay maaari ding gumana, ngunit T ito magiging posible habang ang network ay na-bootstrapped.

Malinaw sa akin na ang isang mahusay na gumaganang Lightning Network ay may malaking potensyal, ngunit maraming hamon ang kailangang malampasan upang matiyak na ito ay matatag din at madaling gamitin.

Ito ay walang pinagkaiba sa Bitcoin o maging sa Internet sa kanilang kamusmusan.

Tulad ng iba pang mga teknolohiya ng network na iyon, mas malamang na makita namin ang pag-aampon kung ang mga kumplikado ay nakatago mula sa mga user sa ilalim ng mga layer ng software. Habang tumatanda ang Kidlat, inaasahan kong makikita nitong paganahin ang mga bagong uri ng pakikipag-ugnayang pang-ekonomiya at pasimulan ang bukang-liwayway ng isa pang rebolusyong pang-ekonomiya.

Disclosure:Sa pagsisikap na mapabuti ang teknikal na pagsusuri, nagbigay ng feedback ang mga developer ng Lightning Network sa artikulong ito.

Electrocution na imahe sa pamamagitan ng Shutterstock