By Bitcoin Časopis - prije 6 mjeseca - Vrijeme čitanja: 6 minute
Stabla vremenskog ograničenja: rješenje za skaliranje LSP-ova Lightning mreže
Jedno od najvećih inherentnih ograničenja Lightning Networku je ograničeni broj kanala koji se mogu otvoriti ili zatvoriti po bloku s obzirom na ograničenje veličine bloka. Bez obzira na to koliko se transakcija može dogoditi izvan lanca koliko jeftino, ovo je temeljno usko grlo koje ograničava koliko bi ljudi moglo realno koristiti Lightning Network. Čak je i Whitepaper Lightning Network prošao u zaključku da u scenariju u kojem cijela svjetska populacija od 7 milijardi koristi Lightning, sa samo dvije on-chain transakcije godišnje po osobi, Bitcoin bilo bi potrebno 133 MB blokova da bi Lightning radio. Ovo nije neki problem izvan lijevog polja ili nepredvidiv problem, to je bilo ograničenje dizajna protokola koji je u potpunosti shvaćen od prvog dana.
Dio plana za rješavanje ovog problema oduvijek je bila ideja o tvornicama kanala, tj. vrsti kanala u kojem sudjeluje više od dva korisnika. Ovo je uvijek bio smjer u kojem su stvari trebale ići kako bi se skalirao Lightning i Bitcoin bez povećanja veličine bloka, ali problem je u tome što rješavanje problema otisaka na lancu uvodi cijeli niz drugih problema. Prije svega, ništa se bitno ne mijenja u vezi sa zahtjevom za provođenjem posrednih stanja ako druga ugovorna strana ne odgovara. To ima implikacije na dodanu vrijednost. Cjelokupna poanta tvornice kanala je da, na primjer, dvadeset ljudi može dijeliti jedan UTXO i preurediti likvidnost unutar njega s ostalih dvadeset ljudi kako god žele. Jednom kada netko zatvori on-chain bez suradnje, to počinje ometati taj cilj.
Ako zatvorim svoj kanal unutar tvornice kanala, povući ću hrpu ljudi sa sobom iz tvornice. Zamislite tvornicu poput stabla merkle, na vrhu je jedan UTXO, koji se dijeli na pola izvan lanca, a oni se dijele na pola, itd. dok ne dođemo do svačijih pojedinačnih kanala. Nakon što izbacim svoj kanal iz tvornice, svi na mojoj strani svakog split-a koji ide u lanac sada su odsječeni od svih ostalih u tvornici. Oni više ne mogu reorganizirati svoju likvidnost u taj dio grupe ako svi surađuju.
Drugi veliki problem je da čak i da biste ga započeli, morate imati sve na mreži na početku kako biste unaprijed potpisali sve transakcije. Ako želite dvadeset ljudi u tvornici, svi moraju biti na mreži da bi je pokrenuli. Ako želite tisuću ljudi, tisuću ljudi mora biti online, itd.
To čini tvornice kanala velikim dizajnerskim prostorom punim puno problema koje treba riješiti. Tako da rješavamo postojeći problem za Lightning, ali stvaramo hrpu novih. Zvuči mi kao inženjering.
Vremensko stablo
Nedavni prijedlog Johna Lawa, Vremensko stablo, pokušava ponuditi rješenje za jedan ključni problem tvornica kanala. Stablo vremenskog ograničenja ne bih baš nazvao tvornicom kanala, više "proto-tvornicom", ali nudi potencijalno rješenje za problem otvaranja i zatvaranja ogromne količine kanala bez uvođenja problema nekooperativnih zatvaranja koja uništavaju korištenje tvornice za druge korisnike. Za funkcionalan rad zahtijeva CHECKTEMPLATEVERIFY (CTV) i pružatelja usluga rasvjete (LSP).
Timeout Tree je u biti tvornica kanala zajamčena sporazumima, bez mogućnosti promjene načina na koji se likvidnost reorganizira izvan lanca nakon što je napravljena, s posebnom klauzulom o izbjegavanju. LSP, nazvat ćemo ih Bob, igra ulogu premošćivanja povremenih korisnika u širu Lightning mrežu. Bob može uzeti novčiće koje kontrolira i stvoriti CTV stablo koje stvara jedan UTXO koji se otvara za otvaranje kanala proizvoljnom broju korisnika njegove LSP usluge. Dobra stvar kod CTV-a je što omogućuje da se to učini bez da svi budu na mreži u isto vrijeme. Bob može jednostavno natjerati svakoga da potpiše svoje početno stanje kanala jednog po jednog i zadržati ih dok svi ne postave kanal, i samo potrošiti sredstva na CTV stablo kada ima postavljene kanale za svakog korisnika.
Ovo rješava problem da svi moraju biti online u isto vrijeme kako bi postavili "tvornicu" i počeli koristiti Lightning. Zbog CTV-a, nakon što Bob potroši novčiće na stablo postavljajući svačije Lightning kanale, ne postoji način da se povuče i uzme novčiće (još). S tim prvim UTXO-om u CTV-u potvrđenim u lancu, svatko može tretirati svoje kanale kao otvorene i nema rizika da budu dvostruko potrošeni.
Sada posljednji dio, zatvaranje kanala. Iako je za njihovo otvaranje potreban samo jedan UTXO u lancu zbog CTV-a, njihovo zatvaranje i dalje bi zahtijevalo da se cijelo CTV stablo razvije u lancu kako bi svatko mogao poslati svoja stanja kanala, zar ne? krivo Ovo je Timeout dio stabala Timeout. Svaka grana u stablu vremenskog ograničenja ima granu skripte u kojoj Bob može počistiti sva sredstva nakon vremenskog zaključavanja.
Dijagram stabla vremenskog ograničenja.Sada sam siguran da razmišljate "što!?" Ovo je prava genijalnost načina na koji ovaj prijedlog funkcionira. Budući da Bob može sam počistiti UTXO-ove u lancu bez ikoga drugog nakon vremenskog zaključavanja, svi ti kanali imaju datum isteka osim ako korisnici zapravo ne razviju cijelo stablo i potvrde stvarno financiranje kanala u lancu. To omogućuje Bobu da učini nešto zgodno: kada dođe to vremensko zaključavanje, on može otvoriti potpuno novo stablo vremenskog ograničenja sa svim korisnicima trenutnog stabla i dati im da premjeste sva svoja sredstva sa stabla koje ističe u novo potpuno isključeno -lanac na Lightningu, a zatim počistite jedan UTXO u lancu posljednjeg stabla.
To omogućuje učinkovito zatvaranje svih ovih kanala u lancu. Jedini preostali problem sada je nametanje HTLC-a u lancu ako druga strana prestane surađivati. Pa...to zapravo i nije problem u ovom slučaju, točnije problem je sve ili ništa. Razlog zašto se kanali moraju zatvoriti da bi se nametnuo HTLC je ako druga strana kanala prestane odgovarati usred usmjeravanja. U stablu vremenskog ograničenja svakom pojedinom korisniku odgovara Bob. Dakle, ako Bob, sve dok je iskren, ne odgovara na ažuriranje neuspjelog ili uspješnog HTLC-a za jednog korisnika, ne odgovara ni za jednog drugog korisnika. U tom slučaju svi još uvijek mogu zatvoriti svoje kanale u lancu prije isteka vremena i prestati koristiti Bobov LSP.
Završavajući
Korisnici će i dalje morati plaćati naknade za interakcije u lancu, to se ne može zaobići, a cijelo stablo vremenskog ograničenja koje se zatvara u lancu bez suradnje bilo bi velik i skup trag u lancu, ali to je u konačnici problem bilo koji sustav višestranačkih kanala morat će se pozabaviti. Timeout Trees međutim ima uvjerljiva rješenja za kooperativni slučaj otvaranja i zatvaranja masivnog višestranačkog kanala bez degradacije modela povjerenja sustava na nešto skrbničko.
John je čak iu svojoj posljednjoj verziji rada predložio shemu u kojoj korisnici mogu biti kažnjeni za nekooperativna zatvaranja dovoljno da pokriju Bobove troškove eventualnog brisanja hrpe fragmentiranih UTXO stabala nakon isteka vremena. Potencijalno postoje načini da se učini obrnuto ako je Bobova neaktivnost ili nepoštenje uzrok zašto korisnici moraju zatvoriti svoj dio stabla bez suradnje.
Na kraju krajeva, ovo je vrlo konkretan i specifičan prijedlog za dizajn tvornice kanala koji zapravo pokušava riješiti stvarna pitanja korištenja i implementacije umjesto poludefiniranog i nejasnog koncepta. To je ogroman napredak u pogledu rješavanja dugoročnih ograničenja skaliranja Lightninga.
Izvorni izvor: Bitcoin Časopis