By Bitcoin Ajakiri - 1 aasta tagasi - Lugemisaeg: 7 minutit
Mõned viisid, kuidas saame Lightningi võrgumaksete marsruutimist uuendada
Selleks, et areneda protokolliks, mida saab kasutada kogu maailm, tuleb Lightningi jaoks kaaluda teatud skaleerimise täiustusi.
Lightning Network on hästi arenenud, kiiresti kasvav 2. kihi tehingulahendus Bitcoin võrku. Üha enam teenuseid ja börse integreerivad seda, maksete suunamiseks saadaolev likviidsus kasvab ning igal aastal töötatakse välja rohkem rakendusi ja viise, kuidas kasutajad sellega suhelda saavad. Sellel on ka palju probleeme, mida pikas perspektiivis ületada:
Skaleeritavus piirab, kui palju kanaleid saab ahelas korraga avada või sulgeda. Probleem on minimaalse suurusega Räsiajaga lukustatud leping (HTLC) suureneb, kuna ketitasud suurenevad, kuna arveldamine peab olema ökonoomne. Samuti on palju privaatsusprobleeme.Üks suur probleem, mida sageli arutatakse, on maksete suunamise likviidsusnõuded. Makse edukaks suunamiseks peab olema kanalite link saatjast saajani, millel on kanali paremal küljel piisavalt likviidsust, et makset edasi saata. See muudab otsuse, kuhu oma mündid võrgus paigutada, väga oluliseks. See tähendab ka seda, et üldine likviidsus, mida inimesed on valmis kasutama, on omamoodi ülempiir, kui palju väärtust võrk suudab töödelda.
Lõppkokkuvõttes taandub see sellele, et kui avate kanali, otsustate selle raha lukustada, et seda saaks kasutada ainult maksete suunamiseks sellele kanalipartnerile ja sellele, kellega nad on graafikul ühendatud. Jah, lõppkokkuvõttes on Lightning Networki idee selles, et tehes piisavalt hüppeid, võite leida ühenduse peaaegu kõikjal. Reaalsus on aga see, et kui keegi teine suudab sooritada makse marsruutimise sihtkohta, kasutades vähem hüppeid kui teie, siis valitakse makse marsruutimiseks tõenäoliselt just see tee. Välk nõuab juba suurel määral ületagatist, st 1 BTC makse suunamiseks 10 hüppega on vaja 10 BTC tagatist lukustada selle marsruudi maksekanalitesse. Konkurents heade ühenduste üle, et teenida marsruutimistulu, süvendab seda, motiveerides veelgi üleliigsemat tagatist.
See on probleem, mis tuleneb asjaolust, et Lightning kanalid on kahe osapoolega "torud", mis võivad lihtsalt väärtust nendes kahes suunas edasi-tagasi lükata. Siin on aga asi: probleem on kujuteldav. Lightningi maksed kasutavad HTLC-sid, skripti a Bitcoin väljund, mis ütleb, et üks inimene saab väljundi taotleda ja seda kulutada, paljastades räsi eelpildi, või teine inimene saab väljundi taotleda ja kulutada pärast ajaluku aegumist ootamist. See on üldine skript, mida saab rakendada ahelas, Lightning-kanalites, olekuahelate peal, külgahelates jne. Niikaua kui saate kasutada HTLC-d, võib teoreetiliselt kõik osaleda Lightningi maksete suunamises.
Olekuketid
A olekuahel on sisuliselt midagi välgukanali sarnast, välja arvatud juhul, kui saate kogu kanali omandiõiguse üle anda ahelast väljas. Nende usaldusmudel sõltub sellest, kas olekuahela operaator (mis võib olla liit) keeldub varasemate omanikega kokkumängust ja varastab olekuahela praeguselt omanikult. See ei ole nii usaldusväärne kui Lightningi kanal, kuid see on palju paindlikum, kuna omandiõigust saab edasi anda ilma ahelasisest tehingut tegemata. Arvestades, et olekuahelad põhinevad eelnevalt allkirjastatud ahelavälistel tehingutel, saate neile lisada HTLC-d.
See võimaldab neid kasutada maksete marsruutimise tõhususe optimeerimiseks Lightningis, võimaldades sõlmede operaatoritel likviidsust ahelast väljudes ümber määrata. Selle asemel, et kanaleid avada ja neisse likviidsust enne tähtaega hästi ühendatud saada, saab nende rahalisi vahendeid ahelast lahkudes dünaamiliselt ümber jaotada vastuseks nõudluse nihutamisele kohtadesse, millega nad ei ole ühendatud (või ei ole piisavalt hästi ühendatud). ). Ainus nõue on, et teine pool soovib likviidsuse suunata olekuahela operaatori usaldamisele.
külgahelad
Külgahelad võivad rakendada mis tahes meelevaldseid reegleid, mida nad soovivad. Ploki ajad võivad olla erinevad, plokkide suurused võivad olla erinevad, kõike saab muuta. Ainus konks praegu on see, et liigutage oma Bitcoin külgahela jaoks peate usaldama föderatsiooni, mis hoiab põhiahela rahalisi vahendeid. Saate rakendada HTLC-sid külgahelale, mis kasutab Bitcoinskriptimissüsteem; teil võib olla rohkem Ethereumi sarnane skriptimissüsteem, mis võimaldab kümnetel inimestel jagada kontot, mis jagab saldod ja värskendab neid vastavalt sellele, kas HTLC õnnestub või ebaõnnestub; sa võid teha kõike. Kuni plokiahel toetab tingimuslikult raha andmist ühele osapoolele, kui nad toodavad räsi, ja teisel poolel pärast ajaluku aegumist, saavad nad aidata välkmakseid suunata. Teised plokiahelad võivad katsetada viise, kuidas muuta likviidsuse jaotamine peamisest tõhusamaks Bitcoin plokiahel. Võite isegi teha midagi nii lihtsat kui ehitada ketti teise Lightning Networki, millel on odavam kanaleid avada ja sulgeda. Piiriks on kujutlusvõime.
Täiesti uued konstruktsioonid
Siin on minu enda juhuslik idee: paljud inimesed saavad kõik kokku kuhjata m-st-n (st 3-5) multisig-aadress mõne tingdeponeerimisagendiga ja lihtsalt usaldage tingdeponeerimisagendid, et asjad õigesti lahendaksid. Kõik aadressil olevad isikud ja tingdeponeerimisagendid saavad maksete marsruutimise alusel jälgida ja värskendada saldosid; registreerige kasutatud HTLC-d ja kas need on edukalt arveldatud või raha tagasi makstud; ja arveldage perioodiliselt saldosid ahelas. Peate lihtsalt koostama multisig-i nii, et multisigist kuluks piisab vaid ühest "marsruutimise" osalejast ja kõigist tingdeponeerimisagentidest. Saate isegi luua ajalukuga tagasimaksetehingu, et tagastada igaühe raha pärast teatud perioodi, mille negatiivne külg oleks see, et kogu raha, mille keegi oli konstruktsiooni eluea jooksul teeninud, läheks selle kasutamisel kaotsi. See nõuaks arveldamist ahelas enne, kui tagasimaksetehing muutub kulutamiseks kehtivaks.
See eeldaks tingdeponeerimisagentide usaldamist, kuid kasu oleks see, et sellesse UTXO rühma kuuluv isik saaks raha üle kanda või HTLC-d suunata mistahes teine isik grupis UTXO. See suurendaks oluliselt likviidsuse jaotamise tõhusust.
Krediidisuhted
Lihtsaim viis tõhususe saavutamiseks oleks lihtsalt inimesi usaldada. Kui saaksite raha teenida, suunates kellegi eest makset üle võrgu, kuid teil pole sõlme jaoks avatud kanalit, mis on vajalik selle makse suunamiseks, siis võite lihtsalt lubada, et maksate need hiljem kui nad sind usaldavad. Kui olite eriti usaldusväärne isik või juriidiline isik ja paljud võrgus olevad inimesed olid valmis teid sel viisil usaldama, siis saaksite makseid suunata tohutult paindlikult ega pea kogu võrgu maksekanalitesse kapitali uputama. Leppige päeva lõpuks ausalt sisse ja inimesed usaldavad teid ka edaspidi, et maksate teie eest tasusüsteemi alusel.
Üks probleem ja eelised
Kõigi nende võimaluste peamiseks eeliseks on see, et vaatamata nende kõigi usaldusmudelite erinevustele (enamik neist eeldab selgelt, et usaldate inimesi, kellega suhtlete, kui otsustate neid kasutada), see pole saatja ja vastuvõtja jaoks üldse oluline. Kui mul on tavaline usaldusväärne välkkanal ja ma tahan maksta kellelegi, kellel on ka usaldusväärne tavapärane välkkanal, ei oma me kummalegi üldse tähtsust, kuidas see makse sinna jõuab. Kui ma raha saadan, värskendatakse seda makset ja jõustatakse minu Lightningi kanalis minu eakaaslasega usaldusväärselt, nagu tavaliselt. Kui vastuvõtja raha tegelikult kätte saab, värskendatakse seda makset ja jõustatakse nende välkkanalis koos eakaaslastega usaldusväärselt, nagu tavaliselt. Asjaolu, et keegi keskel olev inimene lihtsalt usaldab oma eakaaslase lubadust neile hiljem maksta, on meie mõlema jaoks täiesti ebaoluline. Saatsin oma raha ja ei kontrolli enam seda ning saaja sai oma raha tegelikult kätte ja omab nüüd seda usaldamatult.
Probleem on selles, kuidas ma saan saatjana nendest suhetest teada? Lightningis valib saatja makse marsruudi, olles vaadanud makseid edastavate võrgu avalike kanalite marsruutimistabelit. Makse suunamise võimaluse reklaamimiseks on vaja kuvada ahelasisene UTXO, mis rahastas teie Lightningi kanalit, ja tõestada, et see on tegelik kanal. Milles siin probleem seisneb, ükski ülaltoodud ideedest ei suuda seda pakkuda, nii et makse saatja võiks olla teadlik muudest makse suunamise võimalustest. Kui kuulujuttude protokolli ja marsruutimistabeli struktuuri värskendataks, et need muud asjad oleksid lubatud, saaksid nad teada muudest võimalustest.
Ainus reaalne nõue on tagada, et maksete suunamise muude "kanaliväliste" viiside reklaamimine ei avaks teenuse keelamise vektoreid. Praegune skeem, mis nõuab kanalit rahastanud UTXO jagamist, on kaitseks inimeste eest, kes reklaamivad kanaleid, mida pole olemas, mis võib üle koormata sõlmed kasutute kuulujuttude andmetega ja viia kasutajate pidevale püüdmiseni teha makseid, mida pole kunagi olnud. võimalus edu saavutada.
Lõppkokkuvõttes on probleeme, mida tuleb lahendada, et suurendada maksete võrgus suunamise paindlikkust, kuid need on lahendatavad probleemid. Arvata, et välk peab maksevõrgustikuna toimimiseks jätkama nii, nagu ta praegu toimib, on väga kitsas mõtlemine ja otse öeldes – probleemide väljamõtlemine, mis on enamasti väljamõeldud.
See on Shinobi külalispostitus. Avaldatud arvamused on täielikult nende omad ja ei pruugi kajastada BTC Inc või Bitcoin Ajakiri.
Algne allikas: Bitcoin Ajakiri