By Bitcoin Revija - pred 1 letom - Čas branja: 7 minute
Nekaj načinov, kako lahko nadgradimo usmerjanje plačil v omrežju Lightning
Da bi se razvil v protokol, ki ga bo uporabljal ves svet, je treba razmisliti o nekaterih izboljšavah skaliranja za Lightning.
Lightning Network je dobro razvita, hitro rastoča transakcijska rešitev drugega sloja na Bitcoin omrežje. Vse več storitev in borz ga integrira, likvidnost, ki je na voljo za usmerjanje plačil, narašča, vsako leto pa se razvije več aplikacij in načinov za interakcijo uporabnikov z njim. Dolgoročno ima tudi veliko težav, ki jih je treba premagati:
Razširljivost omejuje, koliko kanalov je mogoče hkrati odpreti ali zapreti v verigi. Obstaja težava z najmanjšo velikostjo Časovno zaklenjena pogodba (HTLC) narašča, ko se povečujejo tudi provizije v verigi, ker mora biti poravnava ekonomična. Obstaja tudi vrsta težav z zasebnostjo.Eno od glavnih vprašanj, o katerih se pogosto razpravlja, so likvidnostne zahteve za usmerjanje plačil. Za uspešno usmerjanje plačila mora obstajati povezava kanalov, vse od pošiljatelja do prejemnika, ki ima dovolj likvidnosti na desni strani kanala, da lahko posreduje plačilo. Zaradi tega je odločitev o tem, kje v omrežju namestiti svoje kovance, zelo pomembna. Pomeni tudi, da je celotna količina likvidnosti, ki so jo ljudje pripravljeni uporabiti, nekakšna zgornja meja, koliko vrednosti lahko omrežje obdela.
Navsezadnje se to zmanjša na to, da ko odprete kanal, se odločite zakleniti ta denar, tako da ga je mogoče uporabiti samo za usmerjanje plačil do tega partnerja v kanalu in ne glede na to, s kom je povezan na grafu. Da, navsezadnje je ideja omrežja Lightning Network ta, da lahko z dovolj skoki najdete povezavo s skoraj povsod. Vendar pa je resničnost taka, da če lahko nekdo drug izvede plačilo do cilja z manj skoki kot vi, je to pot, ki bo najverjetneje izbrana za usmerjanje plačila. Lightning že v veliki meri zahteva prekomerno zavarovanje, tj. za preusmeritev plačila 1 BTC prek 10 skokov zahteva 10 BTC zavarovanja, ki mora biti zaklenjenih v plačilnih kanalih vzdolž te poti. Konkurenca v zvezi z dobrimi povezavami za ustvarjanje prihodkov od usmerjanja to poslabšuje s spodbujanjem še večjega odvečnega zavarovanja.
To je težava, ki izhaja iz dejstva, da so kanali Lightning dvostranske "cevi", ki lahko samo potiskajo vrednost naprej in nazaj v ti dve smeri. Tukaj je nekaj: problem je nekako namišljen. Plačila na Lightning uporabljajo HTLC, skript v a Bitcoin izhod, ki pravi, da lahko ena oseba zahteva izhod in ga porabi tako, da razkrije predsliko zgoščeni vrednosti, ali pa lahko druga oseba zahteva izhod in ga porabi po čakanju, da poteče časovna zapora. To je splošni skript, ki ga je mogoče uporabiti v verigi, v kanalih Lightning, na vrhu državnih verig, na stranskih verigah itd. Dokler lahko uporabljate HTLC, lahko teoretično kar koli sodeluje pri usmerjanju plačila Lightning.
Državne verige
A državna veriga je pravzaprav nekaj podobnega kanalu Lightning, le da lahko prenesete lastništvo celotnega kanala v celoti zunaj verige. Njihov model zaupanja je odvisen od operaterja (ki je lahko zveza) državne verige, ki zavrača dogovarjanje s preteklimi lastniki in krajo državne verige trenutnemu lastniku. Ni tako nezaupljiv kot kanal Lightning, vendar je veliko bolj prilagodljiv, saj je lastništvo mogoče prenašati, ne da bi bilo treba izvesti transakcijo v verigi. Glede na to, da verige stanja temeljijo na vnaprej podpisanih transakcijah zunaj verige, jim lahko dodate HTLC.
To jim omogoča, da se uporabljajo za optimizacijo učinkovitosti usmerjanja plačil na Lightning, tako da operaterjem vozlišč omogočijo prerazporeditev likvidnosti na fly off-chain. Namesto da bi morali odpreti kanale in potopiti likvidnost v njih, da bi bili dobro povezani pred časom, se lahko njihova sredstva dinamično prerazporejajo v letenju izven verige kot odgovor na preusmeritev povpraševanja na kraje, s katerimi niso povezani (ali niso dovolj dobro povezani, da ). Edina zahteva je, da druga stran želi preusmeriti likvidnost na zaupanje operaterju verige držav.
Sidechains
Stranske verige lahko izvajajo poljubna pravila, ki jih želijo. Časi blokov so lahko različni, velikosti blokov so lahko drugačne, karkoli je mogoče spremeniti. Edini ulov trenutno je, da premaknete svoj Bitcoin stranski verigi, morate zaupati zvezi, ki skrbi za sredstva v glavni verigi. HTLC-je lahko uporabite na stranski verigi, ki uporablja Bitcoinskriptni sistem; lahko imate skriptni sistem, ki je bolj podoben Ethereumu in omogoča več desetim ljudem, da si delijo račun, ki deli stanja in jih posodablja glede na to, ali HTLC uspe ali ne; lahko narediš karkoli. Dokler veriga blokov podpira pogojno dajanje denarja eni strani, če ustvari zgoščeno vrednost, in drugi strani po izteku časovne zapore, lahko pomaga pri usmerjanju plačil Lightning. Druge verige blokov lahko eksperimentirajo z načini, kako narediti alokacijo likvidnosti učinkovitejšo od glavne Bitcoin blockchain. Lahko celo naredite nekaj tako osnovnega, kot je izgradnja drugega omrežja Lightning Network v verigi, ki je cenejša za odpiranje in zapiranje kanalov. Domišljija je meja.
Povsem nove konstrukcije
Tukaj je moja naključna ideja: veliko ljudi se lahko združi v eno m-od-n (tj. 3-od-5) multisig naslov z nekaj depozitnimi agenti in preprosto zaupajte depozitnim agentom, da bodo zadeve pravilno uredili. Vsaka oseba na naslovu in depozitni agenti lahko sledijo in posodabljajo "stanje" na podlagi usmerjanja plačil; beležite uporabljene HTLC in ali so bili uspešno poravnani ali vrnjeni; in občasno poravnava stanja v verigi. Preprosto sestavite multisig, tako da so en sam udeleženec "usmerjanja" in vsi depozitni agenti vse, kar je potrebno porabiti za multisig. Lahko celo ustvarite časovno zaklenjeno transakcijo vračila, da vsem povrnete denar po določenem obdobju, slaba stran tega pa bi bila, da bi bil ves denar, ki bi ga kdo pridobil med življenjsko dobo konstrukcije, izgubljen, če bi to uporabili. To bi zahtevalo poravnavo v verigi, preden postane transakcija vračila veljavna za porabo.
To bi zahtevalo zaupanje agentom za depozite, vendar bi bila korist ta, da bi katera koli oseba v tej "skupini UTXO" lahko nakazala sredstva ali usmerila HTLC na kaj druga oseba v skupini UTXO. To bi pomenilo ogromno povečanje učinkovitosti pri dodeljevanju likvidnosti.
Kreditna razmerja
Najenostavnejši način za doseganje učinkovitosti bi bil preprosto zaupanje ljudem. Če bi lahko zaslužili z usmerjanjem plačila prek omrežja za nekoga, vendar nimate odprtega kanala do vozlišča, potrebnega za usmerjanje tega plačila, potem lahko le obljubite, da jih boste plačali pozneje če ti zaupajo. Če ste posebej zaupanja vredna oseba ali subjekt in vam je veliko ljudi v omrežju pripravljeno zaupati na ta način, potem lahko usmerjate plačila z veliko mero prilagodljivosti in vam ni treba vlagati kapitala v plačilne kanale po vsem omrežju. Ob koncu dneva se samo pošteno poravnajte in ljudje vam bodo še naprej zaupali, da bodo namesto vas posredovali plačila na podlagi sistema častov.
Ena težava in koristi
Glavna prednost vseh teh možnosti je, da kljub velikim razlikam v modelu zaupanja (večina jih dejansko izrecno zahteva, da zaupate ljudem, s katerimi komunicirate, če se odločite za njihovo uporabo), za pošiljatelja in prejemnika sploh ni pomembno. Če imam običajen kanal Lightning brez zaupanja in želim plačati nekomu, ki ima prav tako običajen kanal Lightning brez zaupanja, nobenemu od naju sploh ni pomembno, kako to plačilo pride tja. Ko pošljem denar, se to plačilo posodobi in uveljavi v mojem kanalu Lightning z mojim vrstnikom brez zaupanja, tako kot običajno. Ko prejemnik dejansko dobi denar, se to plačilo posodobi in uveljavi v njegovem kanalu Lightning pri njegovem vrstniku, nezaupljivo, tako kot običajno. Dejstvo, da nekdo na sredini samo zaupa obljubi vrstnika, da mu bo plačal pozneje, je za oba popolnoma nepomembno. Poslal sem svoj denar in nimam več nadzora nad njim, prejemnik pa je dejansko dobil svoj denar in ga zdaj brez zaupanja nadzoruje.
Težava je, kako naj jaz kot pošiljatelj izvem za ta razmerja? Pri Lightningu je pošiljatelj tisti, ki izbere pot za plačilo po ogledu usmerjevalne tabele javnih kanalov v omrežju, ki so pripravljeni posredovati plačila. Če želite oglaševati možnost usmerjanja plačila, morate prikazati UTXO v verigi, ki je financiral vaš kanal Lightning, in dokazati, da je to dejanski kanal. Kar je tukaj težava, nobena od zgornjih zamisli tega ne bi mogla zagotoviti, tako da bi pošiljatelj plačila lahko vedel za te druge možnosti za usmerjanje plačila. Če sta protokol ogovarjanja in struktura usmerjevalne tabele posodobljena tako, da dovoljujeta te druge stvari, bi lahko bili seznanjeni z drugimi možnostmi.
Edina prava zahteva je zagotoviti, da oglaševanje drugih "nekanalnih" načinov za usmerjanje plačil ne odpre vektorjev zavrnitve storitve. Trenutna shema, ki zahteva skupno rabo UTXO, ki je financiral kanal, obstaja kot zaščita pred ljudmi, ki oglašujejo kanale, ki ne obstajajo, kar bi lahko preobremenilo vozlišča z neuporabnimi podatki o tračih in vodilo do tega, da uporabniki nenehno poskušajo izvesti plačila, ki jih nikoli niso priložnost za uspeh.
Konec koncev obstajajo težave, ki jih je treba rešiti, da bi povečali prilagodljivost načina usmerjanja plačil v omrežju, vendar so te težave rešljive. Mišljenje, da mora Lightning še naprej delovati na način, kot deluje trenutno, da bi lahko deloval kot plačilno omrežje, je zelo ozko razmišljanje in, odkrito povedano, izmišljanje težav, ki so večinoma namišljene.
To je gostujoča objava Shinobija. Izražena mnenja so povsem njihova in ne odražajo nujno mnenj BTC Inc oz Bitcoin Revija.
Izvorni vir: Bitcoin Revija