On Lightning Network – En demonstration i fasthed

HodlX gæstepost  Send dit indlæg

Lightning Network dukkede først op i den whitepaper, der blev foreslået af Joseph Poon og Thaddeus Dryja i 2015. Det genererede store svar og diskussioner blandt Bitcoin-samfundet og er blevet betragtet som den næstvigtigste whitepaper om Bitcoin bag Satoshi Nakamotos banebrydende arbejde.

Da Lightning Network er afhængig af protokollen i Segregated Witness (SegWit), er det stort set forblevet et koncept og har kun udviklet sig internt. Lige siden Bitcoin SegWit-gaffelen i 2017 har udviklingen af ​​Lightning Network støt bevæget sig fremad på rette spor.

I marts 2018 udviklede og lancerede Lightning Labs den første testversion. Senere fulgte ACINQ og Blockstream trop og lancerede en række implementeringer på netværket. Ifølge data fra 1 ml er der i øjeblikket i alt 8.204 noder og 37.901 betalingskanaler på Lightning Network med 1.021.37 BTC (ca. $ 5.34 millioner) på betalingskanalerne, hvilket viser, at Lightning Network har opnået en betydelig vækst i det sidste år.

Lightning Network har til formål at adressere Bitcoins skalerbarhed. Som vi alle ved, blev Bitcoin oprindeligt oprettet som et peer-to-peer elektronisk kontantsystem for at give et decentralt og 24/7 elektronisk betalingsnetværk, men Bitcoins skaleringsproblem er langt fra tilfredsstillende.

Hvis vi beregner ud fra et gennemsnit på 300 noder pr. Handel, er Bitcoin kun i stand til at håndtere 5,6 transaktioner pr. Sekund, mens Visa kan håndtere 47.000 tps ved sin maksimale kapacitet. For at nå denne kapacitet skal Bitcoin udvide sin blokstørrelse til omkring 8 GB, med 400 TB nye blokdata tilføjet hvert år, hvilket naturligvis er urealistisk.

Lightning Network er kun en af ​​de mange løsninger, blockchain-samfundet foreslog for at løse Bitcoins skaleringsproblem, såsom store blokke, DPoS, DAG, sharding, tovejs fastgjort sidekæde, tværkædekommunikation osv..

De foreslog at optimere det grundlæggende inden for distribueret hovedbogsteknologi, f.eks. justering af konfigurationsparametrene, optimering af datastrukturer, ændring af konsensusalgoritmerne, behandling af storbundsdelingen, optimering af netværksressourcer osv., men resultatet var ikke ideelt, og kun meget begrænset præstationsforbedring blev opnået efter alt det hårde arbejde (øg lagerkapacitet, øg netværkstrafik, øge logisk kompleksitet, mindske decentralisering). Sammenlignet med Visa halter Bitcoin stadig betydeligt.

Det ser ud til, at Lightning Network er den ultimative løsning.

På grund af kompleksiteten af ​​Bitcoin-smarte kontrakter er det vanskeligt at forstå de tekniske principper for Lightning Network. OK Research-teamet har derfor genimplementeret sproget Lightning Network with Solidity for at forstå teknologien, der er involveret i implementeringen af ​​Lightning Network. Vi har samlet de grundlæggende procedurer og principper for Lightning Network for dig nedenfor.

Nøgle teknisk princip for lynnetværk

Kernideen i Lightning Network er at skabe midlertidige off-chain betalingskanaler, der giver begge parter mulighed for at udføre ubegrænsede transaktioner off-chain med flere betalingskanaler, men kun den endelige transaktion registreres i blockchain. På denne måde er transaktioner meget mere effektive og øjeblikkelige, da de ikke behøver at vente på, at blokken opdateres. Lightning Network arbejder på, hvordan man undgår at redigere transaktioner uden for kæden.

1. Lightning Network er bygget på tre vigtige koncepter – virtuel bank, engagementstransaktioner og betalingskanaler.

a) Virtuel bank

Smart kontrakt fungerer som en bank. Tag Alice og Bob som et eksempel, en virtuel bank er –

• Skalerbar – Der er kun to konti – Alice og Bob
• Trustless – Åben, gennemsigtig, kan ikke manipuleres, smides eller annulleres
• Brugerens autonomi – Alice og Bob administrerer aktiverne sammen
• Multisignatur – Enhver omfordeling af fonden skal underskrives af både Alice og Bob

b) Forpligtelsestransaktioner

En forpligtelsestransaktion er, når begge parter når til enighed om fordeling af midler og underskriver. Opdateringen sendes ikke straks til blockchain, men gemmes på det lokale netværk.

En forpligtelsestransaktion udtrykker begge parters sande vilje. Det er en aftale om fordeling af midler mellem dem. Transaktionen –

• Kan ikke manipuleres
• Kan ikke smides
• Kan overskrives

c) Betalingskanaler

En betalingskanal er, når begge betalingsparter bruger den virtuelle bank til at frigive deres aktiver og omfordele saldoen på deres indskud gennem gensidig aftale, så værdien kan overføres.

Forpligtelsestransaktion er opdelt i direkte og indirekte forbindelse.

RSMC (Gendannelig sekvensmodningskontrakt) og HTLC (Hashed Timelock-kontrakter)

1. RSMC (kontrakt for tilbagekaldelig sekvensmodning)

Det inkluderer den aktive part, der aktivt indsender forpligtelsestransaktioner til den virtuelle bank til fondstildeling, og den modtagende part, der passivt modtager den allokering, der er indsendt af den aktive part.

RSMC forhindrer ondsindede motiver gennem en tillidsindbetalingsmekanisme.

Når den aktive part initierer en likvidationsanmodning, udbetales den modtagende parts fond, f.eks. $ 100, og returneres straks til den modtagende parts konto. Den aktive parts aktiv ($ 100) låses som et depositum. Låsetiden bestemmes af parameteren freeze_time, der er indstillet af den smarte kontrakt (freeze_time henviser til det tidspunkt, hvor aktiv parts aktiv låses, hvilket kan forhandles af begge parter). Hvis den modtagende part fandt ud af, at den forpligtede transaktion, som den aktive part anmodede om, er blevet tilbagekaldt, kan den modtagende part låse op tilbagekaldelseslåsen inden for låseperioden og tage den aktive parts tillidsindskud som bøde. Tværtimod kan den aktive part efter låseperioden hente deres tillidsindskud.

RSMC er en dobbelt forpligtelse for begge modparter. Hver part opbevarer en kopi af forpligtelsen, og begge kopier er bindende og effektive for den virtuelle bank. Den dobbelte forpligtelse muliggør understøttelse af de tovejs betalingskanaler og undgår en blokering i betalingskanalen på grund af en fejl fra begge sider.

De fælles egenskaber mellem de to forpligtelser – forpligtelsesnummer, balance, frysetid.

Forskellene mellem de to forpligtelser – aktiv og modtagende part, sign part, depositum og tilbagekaldelseslås.

Afviklingsprocessen for RSMC kan opdeles i tre dele.

Åbning af en kanal

• Alice og Bob opretter # 1 RSMC, og hver af dem bidrager med 100 BTC i en fond.

Oprettelse af en forpligtelsestransaktion (betaling)

• Et nyt obligatorisk forhold dannes mellem Alice og Bob. De opretter RSMC nr. 2 og udveksler underskrifter for at opdatere ejerskabet af fonden. Bemærk, at Alice og Bob har modpartens underskrift. Når de først har indtastet deres egen signatur i transaktionen, træder den i kraft med det samme.
• Begge parter udsender den private nøgle til tilbagekaldelseslåsen af ​​# 1 RSMC, som bliver ugyldig på samme tid. RSMC kan løbende udskiftes. Forpligtelsesnummeret stiger med en pr. Erstatning.

Lukning af en kanal

• Alice underskriver på #N RSMC, som allerede inkluderer Bobs signatur, og sender en afviklingsanmodning til den virtuelle bank.
• Som den aktive part frosses Alice’s 50 BTC som et depositum, mens Bobs 150 BTC frigives straks. Når Alis midler er frossne, mislykkes omfordeling, hvis Bob finder tilsagnet om midler, f.eks. # 1 RSMC mislykkes, han kan til enhver tid udløse tilbagekaldelse og kræve også depositum, som han legitimt har ret til.
• Hvis forpligtelsen forbliver gyldig i hele indefrysningsperioden, vil Alice være i stand til at inddrive depositumet.

Selvom RSMC kan opfylde de grundlæggende behov i afviklingsprocessen, har den indlysende begrænsninger. En kanal skal være åben mellem begge parter i RSMC for betaling. For at løse denne begrænsning foreslås Hash Timelock Contract (HTLC). HTLC gør betalingen routing på tværs af to eller flere betalingskanaler.

2. Hash Timelock Contract (HTLC): løsning af atomicitetsproblemer i betalingskanaler

To forhold er involveret i HTLC: Timelock og Hashlock.

• Timelock – kræver, at modtageren bekræfter kvitteringen inden for en tidsperiode (T).
• Hashlock – en part genererer et tilfældigt tal (H) og genererer dets hash (R), hvis den anden del er i stand til at bevise Hash (R) = H, er betalingen gyldig.

I de fleste tilfælde inkluderer HTLC egenskaberne for RSMC. Det fungerer som en bro mellem to altid effektive RSMC’er. En ny RSMC oprettes, hvis betingelserne for tidslås og hashlock er opfyldt. Ellers vil den tidligere RSMC blive vedtaget i stedet.

HTLC betalingsproces

Fra venstre mod højre etablerer en forpligtelse fremad; fra højre til venstre, sender et hashnummer baglæns for at gennemføre betalingen.

• Carol genererer et tilfældigt tal (R), genererer derefter dets hash (H) og sender begge til Alice;
• Alice opretter en HTLC med Bob. Timelåsen er indstillet til 2T. Alice sender H til Bob.
• Bob opretter en HTLC med Carol. Timelåsen er indstillet til T (skal være kortere end 2T). Bob sender H til Carol.
• Carol sender H, den hashede R, til Bob til validering. Hvis antallet matcher inden udløb, oprettes en altid effektiv RSMC baseret på HTLC, og HTLC’en annulleres samtidig og opfylder sit ansvar. Men hvis antallet R ikke stemmer overens, eller betalingen udløber, vil HTLC mislykkes, og betalingen vender tilbage til den sidste RSMC.
• Bob sender nummeret R fra Carol til Alice til validering. Og ovenstående valideringsproces gentages.

Blandt de tre parter er Alice og Carol slutpunkterne for transaktionen, Bob er kun en købmand, der forbinder de to andre parter. Faktisk kan Bob etablere et betalingsforhold med begge parter. For eksempel kan forpligtelserne mellem Bob og Alice og Bob og Carol være forskellige. Bob kan betale Carol $ 9,9 og opkræve Alice $ 10. $ 0,1 vil være overførselsgebyret for Bob.

3. De risici, som de to typer kontrakter forsøger at løse – snyd og atomicitet

• Snyd – hvad nu hvis den anden part er snedig og principløs?
• I RSMC, fra # N-1 til #N-forpligtelser, kan den aktive part drage fordel af sig selv ved ikke at tilbagekalde # N-1-forpligtelse. Derfor skal der tilføjes en yderligere betingelse for den aktive part for udsendelse af tilbagekaldelseslåsen.
• I HTLC, fra # N-1 til #N-forpligtelser, kan kun den modtagende part kun sende det hashede nummer for at modtage betalingen (samme som at tilbagekalde # N-1-forpligtelse). Hvis den aktive part ikke tilbagekalder # N-1-forpligtelse, kan den modtagende part stadig kræve det direkte via den virtuelle bank. For at konkludere opretter HTLC en afbalanceret alt-eller-intet-regel for at undgå, at deltagerne snyder.
• Risikoen ved flere betalingskanaler: atomicitet i nabokanaler

  I betalingsstien opretter den aktive part en HTLC til den modtagende part. Derefter sender den modtagende part den hashede værdi tilbage. Betalinger på venstre side skal være afsluttet før betalinger på højre side.

• For alle formidlere betyder det at modtage betalinger for noder på højre side at modtage det hashede nummer inden for tidslåsen. Og timelåsen på venstre side skal være længere end timelåsen på højre side. Så mellemmændene skal være i stand til at kræve lige kompensation fra knudepunkterne på højre side, hvilket betyder, at fordelene ved formidlere normalt kommer fra siden med en kortere tidslås. Hvis vi forsøger at gå bagud, fuldender knudepunkterne på højre side aldrig nogen betaling, og de kan aldrig modtage det hashede nummer. Så betalingen på venstre side afsluttes heller ikke. Dette er atomiciteten i de omkringliggende kanaler.
• Alt i alt er tillidsmekanismen bygget oven på begge parters autonomi. I beslutningsprocessen underskriver den modtagende part inden den aktive part gør det. Derfor har den aktive part ret til indledende gennemgang, og den aktive part har ret til anden gennemgang. I eksekveringsfasen har den aktive part ret til indsendelse, den virtuelle bank ret til eksekvering og den modtagende part ret til gennemgang inden for en bestemt tidsperiode.

Blockchain Trilemma og Lightning Network Solution

Bitcoin er et peer-to-peer elektronisk kontantsystem. Det er banebrydende, fordi det skabte et digitalt betalingssystem med det unikke træk ved kontantbetalingssystemet – afregning af betaling med det samme. Udveksling af værdi sker straks med udveksling af “symboler af værdi” sammen med aktivoplysningerne og overførsel af kreditors krav og forpligtelser. Digital betaling har kæmpet for at opnå dette, fordi en digital fil kan kopieres eller forfalskes, hvilket er de to mest diskuterede emner inden for digitale betalinger – validering og dobbeltforbrug.

Validering – dette problem blev løst af Bitcoin ved hjælp af en digital signatur. Den, der ejer den private nøgle, ejer Bitcoin.

Dobbeltforbrug – som illustreret i nedenstående diagram, når Bob accepterer Alice’s transaktion, bliver han nødt til at bekræfte, at transaktionen ikke duplikeres ved at kontrollere hele hovedbogen. Forebyggelse af dobbeltforbrug skabte et skalerbarhedsproblem.

Som skrevet af Satoshi Makamoto i Bitcoin – Et peer-to-peer elektronisk kontantsystem:

”Vi har brug for en måde for betalingsmodtageren at vide, at de tidligere ejere ikke underskrev tidligere transaktioner. Til vores formål er den tidligste transaktion den, der tæller, så vi er ligeglade med senere forsøg på at dobbeltbruge. Den eneste måde at bekræfte fraværet af en transaktion er at være opmærksom på alle transaktioner. ”

Den eneste måde at løse dobbeltforbrug på er at erhverve alle transaktionsposter, som Satoshis distribuerede hovedbog er baseret på. Men prisen er uoverkommelig.

• Opbevaring – hver knude skal gemme en kopi af hele hovedbogen
• Validering – hver knude skal validere alle transaktioner
• Kommunikation – hver knude skal kommunikere med hinanden
• Konsensus – hver knude skal levere hashkraft til konsensus

For hver transaktion vil den krævede lagring, beregning og kommunikation være positivt proportional med antallet af valideringsnoder. For at opnå konsensus mellem spredte noder kræver det mere tid. Dette er Blockchain-trilemmaet, som vi altid hører om, vanskelighederne med at opnå decentralisering, sikkerhed og skalerbarhed på samme tid.

Løsninger dukker op for at løse skalerbarhedsproblemet i de senere år, såsom større blokstørrelse, DAG-netværk, nye mekanismer (DPOS, PBFT), sharding og sidekæde. Konsensusmekanismerne som DPOS og PBFT ofrer en grad af decentralisering for skalerbarhed, hvilket reducerer antallet af noder til validering.

De populære sharding- og sidekædeforslag er mere avancerede. Selvom de også reducerer valideringsnoderområdet for at øge konsensuseffektiviteten, integrerede de ideen om “gruppering”, hvilket undgik, at validering ofte udføres på bestemte noder, hvilket sænker manipulationsrisikoen.

Ikke desto mindre er udskæringsteknologi stadig i sin barndom. Mere udforskning og eksperimenter skal endnu udføres på problemer som tilfældighed, balance og afhængighed. Kort sagt, der er endnu ingen absolut opløsning for Blockchain Trilemma. Men Lightning Network skiller sig ud blandt skalerbarhedsløsninger uden for kæden.

Logikken bag Lightning Network er enkel. Det er ikke begrænset af “peer-to-peer cash system”. I stedet introducerede den en gældsoverførselsmekanisme, der minder meget om bankoverførsel. Overførslen mellem Alice og Bob er ikke længere ejerskabet af aktivet, men gælden til en virtuel bank. Den dobbelte udgiftsløsning er forenklet – Bob skal nu kun bekræfte med den virtuelle bank på kontosaldoen i stedet for at bekræfte med hele netværket på Alice’s overførselsoptegnelse. Lightning Networks virtuelle bank involverer dog ikke ideen om en central mellemhandler, men en smart kontrakt bruges i stedet for at garantere den virtuelle banks gældsafvikling..

Under alle omstændigheder opnåede Lightning Network at reducere et betydeligt antal transaktioner, der kræver fuld konsensus. Ved at opbygge en off-chain betalingskanal opfylder den validering og dobbeltforbrugsforebyggelse med uendelige grupper. Da der ikke er nogen afhængighed mellem off-chain-grupperne, minimerer det risikoen, som en del af netværket pålægger hele netværket.

Fordele ved Lightning Network

Fem hovedfordele ved lynnetværket:

Lavt transaktionsgebyr

• Minearbejdere er ikke påkrævet. Der opkræves mindre gebyrer for brug af betalingskanaler mellem noder.

Bekræftelse i realtid

• Et mindre antal noder i deltagelse. Transaktioner gennemføres generelt mellem hundreder af millisekunder til et par sekunder.

Høj parallel behandlingskapacitet

• Kanalkapacitet = Bitcoin TPS x 3.600 x 24 x Gennemsnitlig kanalalder / 4 = 3.952.800
• Parallel behandlingskapacitet = Kanalkapacitet / kanaler optaget pr. Transaktion = 658.880

  * den gennemsnitlige kanalalder er hentet; kanaler optaget pr. transaktion er som standard 6 baseret på de seks adskillelsesgrader.

Lille størrelse

• De fleste data lagres uden for kæden, hvilket frigør lagerplads på blockchain.

Anonymitet

• Transaktioner er uden for kæden og er næsten umulige at spore.

I de næste kapitler vil vi dykke dybere og undersøge, hvorfor gældsafviklingsmodellen ville være mere effektiv, og også ulemperne ved Lightning Network og nye løsninger.

Dette indlæg optrådte oprindeligt på Medium. Læs mere.

Om OKEx

OKEx er en verdensførende digital aktivudveksling med hovedkontor i Malta og tilbyder omfattende digitale aktiver handelstjenester inklusive tokenhandel, futures trading, evig swap handel og indeks tracker til globale handlende med blockchain teknologi. I øjeblikket tilbyder børsen over 400 token- og futures-handelspar, der gør det muligt for brugere at optimere deres strategier.