On Lightning Network – En demonstrasjon i soliditet

HodlX gjestepost  Send inn innlegget ditt

Lightning Network dukket først opp i whitepaper foreslått av Joseph Poon og Thaddeus Dryja i 2015. Det genererte store svar og diskusjoner blant Bitcoin-samfunnet og har blitt ansett som den nest viktigste whitepaper på Bitcoin bak Satoshi Nakamotos banebrytende arbeid.

Siden Lightning Network er avhengig av protokollen i Segregated Witness (SegWit), har det stort sett vært et konsept og har bare utviklet seg internt. Helt siden Bitcoin SegWit-gaffelen i 2017 har utviklingen av Lightning Network gått fremover på riktig vei.

I mars 2018 utviklet og lanserte Lightning Labs den første testversjonen. Senere fulgte ACINQ og Blockstream etter og lanserte en rekke implementeringer på nettverket. I henhold til dataene fra 1 ml er det for tiden totalt 8 204 noder og 37 901 betalingskanaler på Lightning Network, med 1 021,37 BTC (cirka 5,34 millioner dollar) på betalingskanalene, noe som viser at Lightning Network har oppnådd betydelig vekst det siste året.

Lightning Network hadde som mål å adressere Bitcoins skalerbarhet. Som vi alle vet, ble Bitcoin opprinnelig opprettet som et peer-to-peer elektronisk kontantsystem for å gi et desentralisert og 24/7 elektronisk betalingsnettverk, men Bitcoins skaleringsproblem er langt fra tilfredsstillende.

Hvis vi beregner basert på et gjennomsnitt på 300 noder per handel, er Bitcoin bare i stand til å håndtere 5,6 transaksjoner per sekund, mens Visa kan håndtere 47 000 tps ved sin maksimale kapasitet. For å nå denne kapasiteten, vil Bitcoin trenge å utvide blokkstørrelsen til rundt 8 GB, med 400 TB nye blokkeringsdata lagt til hvert år, noe som åpenbart er urealistisk..

Lightning Network er bare en av de mange løsningene blockchain-samfunnet foreslo for å løse Bitcoins skaleringsproblem, som store blokker, DPoS, DAG, sharding, toveis festet sidekjede, kryss-kjedekommunikasjon, etc.

De foreslo å optimalisere det grunnleggende om distribuert hovedboksteknologi, f.eks. justering av konfigurasjonsparametrene, optimalisering av datastrukturer, modifisering av konsensusalgoritmene, resirkuleringsdelingsbehandling, optimalisering av nettverksressurser osv., men resultatet var ikke ideelt, og bare svært begrenset ytelsesforbedring ble oppnådd etter alt hardt arbeid (øke lagringskapasiteten, øke nettverkstrafikk, øke logikkens kompleksitet, redusere desentralisering). Sammenlignet med Visa henger fortsatt Bitcoin betydelig.

Det ser ut til at Lightning Network er den ultimate løsningen.

På grunn av kompleksiteten i Bitcoin smarte kontrakter er det vanskelig å forstå de tekniske prinsippene til Lightning Network. OK Research-teamet har derfor implementert Lightning Network with Solidity-språket på nytt for å forstå teknologien som er involvert for implementering av Lightning Network. Vi har oppsummert de grunnleggende prosedyrene og prinsippene til Lightning Network for deg nedenfor.

Nøkkel teknisk prinsipp for lynnettverk

Kjerneideen til Lightning Network er å opprette midlertidige off-chain betalingskanaler som gjør at begge parter kan utføre ubegrensede transaksjoner off-chain med flere betalingskanaler, men bare den endelige transaksjonen blir registrert på blockchain. På denne måten er transaksjoner mye mer effektive og øyeblikkelige, da de ikke trenger å vente på at blokken skal oppdateres. Lightning Network jobber med å hindre at off-chain transaksjoner blir redigert.

1. Lightning Network bygger på tre viktige konsepter – virtuell bank, forpliktelsestransaksjoner og betalingskanaler.

a) Virtual Bank

Smart kontrakt fungerer som en bank. Ta Alice og Bob som et eksempel, en virtuell bank er –

• Skalerbar – Det er bare to kontoer – Alice og Bob
• Tillitsløs – Åpen, gjennomsiktig, kan ikke tukles, smides eller kanselleres
• Brukerens autonomi – Alice og Bob administrerer eiendelene sammen
• Flersignatur – Enhver omfordeling av fondet må signeres av både Alice og Bob

b) Forpliktelsestransaksjoner

En forpliktelsestransaksjon er når begge parter når enighet om fordeling av midler og signerer. Oppdateringen sendes ikke umiddelbart til blockchain, men lagres på det lokale nettverket.

En forpliktelsestransaksjon uttrykker begge parters sanne vilje. Det er en avtale om fordeling av midler mellom dem. Transaksjonen –

• Kan ikke tukles
• Kan ikke smides
• Kan overskrives

c) Betalingskanaler

En betalingskanal er når begge betalingspartene bruker den virtuelle banken til å sperre eiendelene sine og omfordele balansen av innskuddene sine gjennom gjensidig avtale, slik at verdien kan overføres.

Forpliktelsestransaksjon er delt inn i direkte og indirekte tilknytning.

RSMC (Recoverable Sequence Maturity Contract) og HTLC (Hashed Timelock Contracts)

1. RSMC (Revocable Sequence Maturity Contract)

Den inkluderer den aktive parten, som aktivt sender forpliktelsestransaksjoner til den virtuelle banken for fondstildeling, og den mottakende parten, som passivt mottar tildelingen sendt av den aktive parten.

RSMC forhindrer ondsinnede motiver gjennom en tillitsinnskuddsmekanisme.

Når den aktive parten initierer en likvidasjonsforespørsel, vil mottakers fond, si $ 100, bli utbetalt og returneres til mottakers konto umiddelbart. Aktivt aktivum ($ 100) blir låst som et depositum. Låsetiden bestemmes av freeze_time-parameteren som er angitt av den smarte kontrakten (freeze_time refererer til den tiden aktiv parts aktiva låses, som kan forhandles av begge parter). Hvis mottakerparten fant ut at forpliktelsestransaksjonen som den aktive parten ba om, har blitt tilbakekalt, kan mottakerparten låse opp tilbakekallingslåsen innen låseperioden og ta den aktive partens tillitsinnskudd. Tvert imot, etter låseperioden, kan den aktive parten hente sitt tillitsinnskudd.

RSMC er et dobbelt engasjement for begge motparter. Hver part beholder en kopi av forpliktelsen, og begge kopiene er bindende og effektive for den virtuelle banken. Den doble forpliktelsen tillater støtte fra toveis betalingskanaler, og unngår en blokk i betalingskanalen på grunn av en feil fra begge sider.

De vanlige egenskapene mellom de to forpliktelsene – forpliktelsesnummer, balanse, frysetid.

Forskjellene mellom de to forpliktelsene – aktiv og mottakende part, signparti, depositum og tilbakekallingslås.

Bosettingsprosessen til RSMC kan deles inn i tre deler.

Åpne en kanal

• Alice og Bob oppretter nr. 1 RSMC, og hver av dem bidrar med 100 BTC til et fond.

Opprette en forpliktelsestransaksjon (betaling)

• Et nytt obligatorisk forhold dannes mellom Alice og Bob. De vil opprette RSMC nr. 2 og utveksle signaturer for å oppdatere eierskapet til fondet. Merk at Alice og Bob har signaturen til motparten. Når de har lagt inn sin egen signatur i transaksjonen, vil den tre i kraft med en gang.
• Begge parter sender den private nøkkelen for tilbakekallingslåsen av # 1 RSMC, som blir ugyldig samtidig. RSMC kan skiftes kontinuerlig. Forpliktelsestallet øker med en per erstatter.

Lukke en kanal

• Alice signerer på #N RSMC, som allerede inkluderer Bobs signatur, og sender inn en forliksforespørsel til den virtuelle banken.
• Som aktiv fest blir Alice’s 50 BTC frosset som et sikkerhetsdepositum, mens Bobs 150 BTC frigjøres umiddelbart. Når Alice sine midler er frosset, mislykkes omfordeling av Bob hvis Bob finner tilsagnet om midler, f.eks. # 1 RSMC mislykkes, han kan utløse tilbakekalling når som helst og kreve også sikkerhetsdepositumet, som han legitimt har krav på.
• Hvis forpliktelsen forblir gyldig gjennom hele innfrysingsperioden, vil Alice kunne kreve tilbake depositumet.

Selv om RSMC kan oppfylle de grunnleggende behovene til bosettingsprosessen, har den åpenbare begrensninger. En kanal må være åpen mellom begge parter i RSMC for betaling. For å løse denne begrensningen foreslås Hash Timelock Contract (HTLC). HTLC gjør betalingen rutbar på tvers av to eller flere betalingskanaler.

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

To forhold er involvert i HTLC: Timelock og Hashlock.

• Tidslås – krever at mottakeren bekrefter kvitteringen innen en tidsperiode (T).
• Hashlock – den ene parten genererer et tilfeldig tall (H) og genererer hash (R), hvis den andre delen er i stand til å bevise Hash (R) = H, er betalingen gyldig.

I de fleste tilfeller inkluderer HTLC egenskapene til RSMC. Det fungerer som en bro mellom to alltid effektive RSMC-er. En ny RSMC vil bli etablert hvis tidslåsen og hashlock-vilkårene er oppfylt. Ellers vil forrige RSMC bli vedtatt i stedet.

HTLC betalingsprosess

Fra venstre til høyre, etablere en forpliktelse fremover; fra høyre til venstre, og sender et hashnummer bakover for å fullføre betalingen.

• Carol genererer et tilfeldig tall (R), genererer deretter hash (H) og sender begge til Alice;
• Alice setter opp en HTLC med Bob. Tidslåsen er satt til 2T. Alice sender H til Bob.
• Bob setter opp en HTLC med Carol. Tidslåsen er satt til T (må være kortere enn 2T). Bob sender H til Carol.
• Carol sender H, den hashede R, til Bob for validering. Hvis antallet samsvarer før utløpet, vil en alltid effektiv RSMC bli etablert basert på HTLC, og HTLC vil bli kansellert samtidig og oppfylle sitt ansvar. Men hvis tallet R ikke samsvarer eller betalingen utløper, vil HTLC mislykkes og betalingen vil gå tilbake til den siste RSMC.
• Bob vil sende nummeret R fra Carol til Alice for validering. Og ovenstående valideringsprosess gjentas.

Blant de tre partiene er Alice og Carol endepunktene for transaksjonen, Bob er bare en kjøpmann for å koble de to andre partiene sammen. Faktisk kan Bob etablere et betalingsforhold med begge parter. For eksempel kan forpliktelsene mellom Bob og Alice og Bob og Carol være forskjellige. Bob kan betale Carol $ 9,9 og belaste Alice $ 10. $ 0,1 vil være overføringsgebyret for Bob.

3. Risikoen som de to typene kontrakter prøver å løse – juks og atomicitet

• Juks – hva om den andre parten er lur og prinsipiell?
• I RSMC, fra # N-1 til #N-forpliktelser, kan den aktive parten dra nytte av seg selv ved ikke å oppheve # N-1-forpliktelse. Derfor må det legges til en tilleggsvilkår for den aktive parten for kringkasting av tilbakekallingslåsen.
• I HTLC, fra # N-1 til #N-forpliktelser, er det bare mottakeren som bare kan kringkaste nummeret for å motta betalingen (det samme som å tilbakekalle # N-1-forpliktelse). Hvis den aktive parten ikke tilbakekaller # N-1-forpliktelse, kan den mottakende parten fortsatt kreve det direkte via den virtuelle banken. For å konkludere, etablerer HTLC en balansert alt-eller-ingenting-regel for å unngå at deltakerne jukser.
• Risikoen ved flere betalingskanaler: atomiciteten til nabokanalene

  I betalingsstien oppretter den aktive parten en HTLC til mottakeren. Deretter sender mottakeren den hashverdien bakover. Betalinger på venstre side må fullføres før de på høyre side.

• For alle mellomledd betyr å fullføre betalinger for noder på høyre side å motta det hashede nummeret innen tidlåsen. Og tidlåsen på venstre side må være lengre enn tidlåsen på høyre side. Så mellommennene må kunne kreve lik kompensasjon fra nodene på høyre side, noe som betyr at fordelene til mellommenn vanligvis kommer fra siden med en kortere tidlås. Hvis vi prøver å gå bakover, fullfører nodene på høyre side aldri noen betaling, og de kan aldri motta nummeret. Så betalingen på venstre side vil heller aldri fullføres. Dette er atomiciteten til nabokanalene.
• I det hele tatt er tillitsmekanismen bygget på toppen av begge parters autonomi. I beslutningsfasen signerer mottakerparten før den aktive parten gjør det. Derfor har den aktive parten rett til innledende gjennomgang, og den aktive parten har rett til andre gjennomgang. I utførelsesfasen har den aktive parten rett til innlevering, den virtuelle banken rett til utførelse, og den mottakende parten retten til gjennomgang innen en viss tidsperiode.

Blockchain Trilemma og Lightning Network Solution

Bitcoin er et peer-to-peer elektronisk kontantsystem. Det er banebrytende fordi det opprettet et digitalt betalingssystem med den unike funksjonen i kontantbetalingssystemet – avregning av betaling umiddelbart. Verdiutvekslingen skjer umiddelbart med utveksling av “symboler av verdi”, sammen med aktivainformasjonen og overføring av kreditors krav og forpliktelser. Digital betaling har slitt med å oppnå dette fordi en digital fil kan dupliseres eller forfalskes, som er de to mest omtalte spørsmålene innen digitale betalinger – validering og dobbeltbruk.

Validering – dette problemet ble løst av Bitcoin ved hjelp av en digital signatur. Den som eier den private nøkkelen, eier Bitcoin.

Dobbel utgift – som illustrert i diagrammet nedenfor, når Bob godtar Alice’s transaksjon, må han bekrefte at transaksjonen ikke dupliseres ved å sjekke hele hovedboken. Å forhindre dobbeltbruk skapte et skalerbarhetsproblem.

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

“Vi trenger en måte for betalingsmottakeren å vite at de tidligere eierne ikke signerte tidligere transaksjoner. For våre formål er den tidligste transaksjonen den som teller, så vi bryr oss ikke om senere forsøk på å dobbeltbruke. Den eneste måten å bekrefte fraværet av en transaksjon er å være klar over alle transaksjoner. ”

Den eneste måten å løse dobbeltbruk er å skaffe seg alle transaksjonsregistrene, som Satoshis distribuerte hovedbok er basert på. Men kostnaden er uoverkommelig.

• Lagring – hver node må lagre en kopi av full reskontro
• Validering – hver node må validere alle transaksjoner
• Kommunikasjon – hver node må kommunisere med hverandre
• Konsensus – hver node må gi hashkraft for konsensus

For hver transaksjon vil den nødvendige lagring, beregning og kommunikasjon være positivt proporsjonal med antall valideringsnoder. For å oppnå konsensus mellom spredte noder krever det mer tid. Dette er Blockchain Trilemma vi alltid hører om, vanskeligheten med å oppnå desentralisering, sikkerhet og skalerbarhet samtidig.

Løsninger dukker opp for å løse skalerbarhetsproblemet de siste årene, som større blokkstørrelse, DAG-nettverk, nye mekanismer (DPOS, PBFT), skjæring og sidekjede. Konsensusmekanismene som DPOS og PBFT ofrer en grad av desentralisering for skalerbarhet, og reduserer antall noder for validering.

Trending sharding og sidekjedeforslagene er mer avanserte. Selv om de også reduserer valideringsnodene for å øke konsensuseffektiviteten, integrerte de ideen om “gruppering”, som unngikk at validering ofte gjøres på bestemte noder, noe som reduserer manipulasjonsrisikoen..

Likevel er skjæringsteknologi fortsatt i sin barndom. Mer leting og eksperimenter er ennå ikke utført på problemer som tilfeldighet, balanse og avhengighet. Enkelt sagt, det er ingen absolutt oppløsning for Blockchain Trilemma ennå. Men Lightning Network skiller seg ut blant skalerbare løsninger utenfor kjeden.

Logikken bak Lightning Network er enkel. Det er ikke begrenset av “peer-to-peer cash system”. I stedet introduserte den en gjeldsoverføringsmekanisme som er veldig lik bankoverføring. Overføringen mellom Alice og Bob er ikke lenger eierskapet til eiendelen, men gjelden til en virtuell bank. Den doble forbruksløsningen er forenklet – Bob må nå bare bekrefte den virtuelle banken på kontosaldoen, i stedet for å bekrefte med hele nettverket på Alice’s overføringsjournal. Lightning Networks virtuelle bank involverer imidlertid ikke ideen om en sentralisert mellommann, en smart kontrakt brukes i stedet for å garantere gjeldsordning av den virtuelle banken..

Uansett oppnådde Lightning Network å redusere et betydelig antall transaksjoner som krever full konsensus. Ved å bygge en betalingskanal utenfor kjeden, oppfyller den validering og dobbeltforebygging med uendelige grupper. Ettersom det ikke er noen avhengighet mellom gruppene utenfor kjeden, minimerer det risikoen som en del av nettverket pålegger hele nettverket.

Fordeler med Lightning Network

Fem hovedfordeler med lynnettverket:

Lavt transaksjonsgebyr

• Minearbeidere er ikke påkrevd. Små avgifter påløper for bruk av betalingskanaler mellom noder.

Bekreftelse i sanntid

• Et mindre antall noder i deltakelse. Transaksjoner gjennomføres vanligvis mellom hundrevis av millisekunder til noen få sekunder.

Høy parallell behandlingskapasitet

• Kanalkapasitet = Bitcoin TPS x 3600 x 24 x Gjennomsnittlig kanalalder / 4 = 3.952.800
• Parallell behandlingskapasitet = Kanalkapasitet / Kanaler okkupert per transaksjon = 658.880

  * gjennomsnittlig kanalalder er hentet; kanaler okkupert per transaksjon er standard som 6 basert på de seks skillene.

Liten størrelse

• De fleste data lagres utenfor kjeden, noe som frigjør lagringsplass på blockchain.

Anonymitet

• Transaksjoner er utenfor kjeden og er nesten umulige å spore.

I de neste kapitlene vil vi dykke dypere og utforske hvorfor gjeldsordningmodellen ville være mer effektiv, og også ulempene med Lightning Network og nye løsninger.

Dette innlegget dukket opprinnelig opp på Medium. Les mer.

Om OKEx

OKEx er en verdensledende digital eiendomsutveksling med hovedkontor på Malta, og tilbyr omfattende tjenester for handel med digitale eiendeler, inkludert tokenhandel, futures trading, evigvarende byttehandel og indekssporing til globale handelsmenn med blockchain-teknologi. For tiden tilbyr børsen over 400 token- og futures-handelspar som gjør det mulig for brukere å optimalisere sine strategier.