Viktig information
Lager 2-lösningarna skapades för att ta itu med blockkedjeteknikens inneboende skalbarhetsbegränsningar.
Lightning Nätverk är en lager 2-skalningslösning som erbjuder snabba transaktioner utan behov av blockbekräftelse, vilket möjliggör effektiva mikrobetalningar.
Det säkerställer säkra och skalbara betalningar via multisignaturadresser och Hash Timelock-kontrakt.
Introduktion
Kryptovalutor har flera ganska unika egenskaper. De kan inte hackas eller stängas av hur som helst och vem som helst kan använda dem för att överföra tillgångar runt om i världen utan en tredje part.
För att säkerställa att dessa funktioner kvarstår måste betydande avvägningar göras. Eftersom många noder är ansvariga för att driva ett kryptovalutanätverk är genomströmningen begränsad. Som ett resultat av detta är antalet transaktioner per sekund (TPS) som ett blockkedje-nätverk kan bearbeta relativt lågt för en teknik som syftar till att anammas av massorna.
För att övervinna blockkedjeteknologins inneboende begränsningar har ett antal skalbarhetslösningar föreslagits, för att öka antalet transaktioner som ett nätverk kan hantera. I den här artikeln gör vi en djupdykning i Lightning-nätverket, som är en förlängning av Bitcoin-protokollet.
Vad är Lightning-nätverket?
Lightning-nätverket är ett nätverk som sitter ovanpå en blockkedja för att underlätta snabba peer-to-peer-transaktioner. Det är inte exklusivt för bitcoin – även andra kryptovalutor som litecoin har integrerat det.
Du kanske undrar vad vi menar med "sitter ovanpå en blockkedja." Lightning-nätverket är vad som kallas en lösningutanför kedjan ellerlager två-lösning. Det tillåter personer att göra transaktioner utan att behöva registrera varje transaktion i blockkedjan.
Lightning-nätverket är separat från Bitcoin-nätverket – det har sina egna noder och mjukvara, men det kommunicerar ändå med huvudkedjan. För att komma in i eller lämna Lightning-nätverket måste du skapa speciella transaktioner på blockkedjan.
Vad du faktiskt gör med din första transaktion är att bygga ett slags smart kontrakt med en annan användare. Vi kommer att gå in på detaljerna inom kort – men till en början kan du föreställa dig det smarta kontraktet som en privat redovisning med den andra användaren. Du kan skriva många transaktioner till denna orderbok. De är bara synliga för dig och din motpart, men ingen av er kan fuska på grund av vissa speciella funktioner i konfigurationen.
Denna miniorderbok kallas för en kanal. Säg att Alice och Bob lägger 5 BTC vardera i det smarta kontraktet. I deras kanal skulle då båda nu ha en balans på 5 BTC. Alice kan sedan skriva "betala 1 BTC till Bob" i orderboken. Nu har Bob 6 BTC på sin sida och Alice har 4. Sedan kan Bob skicka 2 BTC tillbaka till Alice vid ett senare tillfälle och uppdatera balansen till 6 BTC på Alices sida och 4 BTC på Bobs. De kan fortsätta göra detta ett tag.
När som helst kan båda publicera det aktuella tillståndet för kanalen till blockkedjan. Vid den tidpunkten allokeras balansen på varje sida av kanalen till deras respektive parter i kedjan.
Som namnet antyder går Lightning-transaktioner blixtsnabbt. Det finns inga blockbekräftelser att vänta på – betalningarna kan göras så snabbt som din internetanslutning tillåter.
Varför är Lightning-nätverket nödvändigt?
Hittills verkar Lightning-nätverket (eller helt enkelt LN) vara det mest förnuftiga sättet att skala Bitcoin-blockkedjan. Det är svårt att samordna förändringar i ett så stort ekosystem – det finns risk för hårda gafflar och potentiellt katastrofala buggar. Med så mycket värde på spel är ett experimenterande otroligt farligt.
När du flyttar det experimentet bort från blockkedjan ger det dig mycket mer flexibilitet. Om något går fel har det inte någon inverkan på det riktiga Bitcoin-nätverket. Lager två-lösningar riskerar inte något av säkerhetsantagandena som har hållit protokollet igång i över 10 år.
Det finns inte heller någon skyldighet att byta från det gamla sättet att göra transaktioner. Transaktionerna i kedjan fortsätter att fungera som vanligt för slutanvändaren, men de har nu också möjlighet att utföra transaktioner utanför kedjan.
Det finns flera fördelar med att använda Lightning-nätverket. Vi ska titta på några av de viktigaste nedan.
Skalbarhet
Bitcoin-block skapas ungefär var tionde minut och kan bara hålla ett visst antal transaktioner. Blockutrymmet är en knapp resurs, så du måste lägga bud mot andra användare för att få ditt inkluderat i tid. Miners bryr sig först och främst om att få betalt, så de inkluderar transaktioner med högre avgifter först.
När det inte finns många användare som försöker skicka tillgångar samtidigt, är detta egentligen inget problem. Du kan ställa in en låg avgift, så kommer du sannolikt att få transaktionen inkluderad i nästa block. Men när för många användare sänder transaktioner samtidigt kan den genomsnittliga avgiften stiga avsevärt. Det fanns flera tillfällen där det översteg 10 USD. På toppen av tjurmarknaden 2017 översteg den 50 USD. I april 2021 översteg den genomsnittliga transaktionsavgiften för Bitcoin 60 USD.
Det kan tyckas obetydligt för transaktioner som flyttar bitcoin till ett värde av tusentals dollar, men för mindre betalningar är detta inte hållbart. Vem vill betala för en kaffe på 3 USD med en avgift på 5 USD?
Med Lightning-nätverket betalar du fortfarande två avgifter – en för att öppna din kanal och en för att stänga den. Men du och din motpart kan göra tusentals transaktioner gratis, när kanalen väl är öppen. När ni är klara behöver ni bara publicera det slutliga tillståndet till blockkedjan.
Om fler användare litar på lösningar utanför kedjan som Lightning-nätverket kommer blockutrymmet att användas mer effektivt på det stora hela. Högfrekventa överföringar med lågt värde skulle kunna utföras i betalningskanaler, medan blockutrymmet används för större transaktioner och öppning/stängning av kanalen. Det skulle göra systemet tillgängligt för en mycket bredare användarbas, vilket också gör att det kan skalas i det långa loppet.
Mikrobetalningar
Det finns en minsta mängd bitcoin som du kan skicka i en transaktion – cirka 0,00000546 BTC. I skrivande stund är detta lika med cirka fyra cent. Det är en liten summa, men Lightning-nätverket låter dig tänja på gränserna för att handla den minsta enheten som är tillgänglig för närvarande – 0,00000001 BTC, eller en satoshi.
Lightning är mycket mer tilltalande för mikrobetalningar. Avgifterna för vanliga transaktioner gör det opraktiskt att skicka små belopp på huvudkedjan. Inom en kanal är du dock fri att skicka en bråkdel av en bitcoin gratis.
Mikrobetalningar lämpar sig för många användningsområden. Vissa spekulerar i att de kan vara en gångbar ersättning för prenumerationsbaserade modeller, där användarna istället betalar små summor varje gång de använder en tjänst.
Sekretess
En sekundär fördel med Lightning-nätverket är att det kan erbjuda användarna en hög grad av konfidentialitet. Parterna behöver inte göra sina kanaler kända för hela nätverket. Även om du kanske kan titta på blockkedjan och säga att denna transaktion öppnade en kanal kommer du inte nödvändigtvis att kunna se vad som händer inuti den. Om deltagarna väljer att göra sin kanal privat är det bara de som vet vilka transaktioner som har ägt rum.
Om Alice har en kanal med Bob och Bob har en kanal med Carol, kan Alice och Carol skicka betalningar till varandra via Bob. Om Dan är ansluten till Carol kan Alice skicka betalningar till honom. Du kan säkert föreställa dig att detta expanderar till ett vidsträckt nätverk av sammankopplade betalningskanaler. I ett sådant upplägg kan du inte vara säker på vem Alice har skickat tillgångar till när kanalen väl är stängd.
Hur fungerar Lightning-nätverket?
Vi har förklarat hur Lightning-nätverket förlitar sig på kanaler mellan noder på en hög nivå. Låt oss nu ta en närmare titt.
Multisignatursadresser
En multisignatursadress (eller multisigadress) är en som flera privata nycklar kan spendera från. När du skapar en anger du hur många privata nycklar som kan spendera tillgångarna och hur många av dessa nycklar som krävs för att underteckna en transaktion. Till exempel innebär ett 1-av-5-schema att fem nycklar kan producera en giltig signatur och att endast en behövs. Ett 2-av-3-schema indikerar att av de tre möjliga nycklarna krävs två valfria för att spendera tillgångarna.
För att initiera en Lightning-kanal låser deltagarna in tillgångarna i ett 2-av-2-schema. Det finns bara två privata nycklar som kan signeras och båda behövs för att flytta coin. Låt oss nu gå tillbaka till våra vänner Alice och Bob. De kommer att göra många betalningar till varandra under de kommande månaderna, så de bestämmer sig för att öppna en Lightning nätverkskanal.
Detta börjar med att de båda sätter in, låt säga, 3 BTC vardera i den gemensamt ägda multisignatursadressen. Bob kan alltså inte flytta tillgångar från adressen utan att Alice går med på det, eller vice versa.
Nu kan de justera balansen på varje sida genom att helt enkelt skriva ner allt på ett pappersark. Båda har en startbalans på 3 BTC. Om Alice vill göra en betalning på 1 BTC till Bob, så varför inte bara notera att Alice nu äger 2 BTC och Bob äger 4 BTC? Balansen kan uppdateras så här tills de bestämmer sig för att flytta ut tillgångarna.
Detta är möjligt att göra, men hur roligt är det? Och ännu viktigare – är det inte otroligt lätt för någon att låta bli att samarbeta? Om Alice till slut har 6 BTC och Bob ingen, förlorar Bob ingenting genom att vägra släppa tillgångarna (förutom sin vänskap med Alice då).
Hash Timelock Contracts (HTLC:er)
Systemet ovan är tråkigt och erbjuder inte mycket utöver dagens pålitliga konfigurationer. Det hela blir mycket mer intressant när vi introducerar en mekanism som upprätthåller "kontraktet" mellan Alice och Bob. Om en av parterna bestämmer sig för att inte följa reglerna har den andra fortfarande ett sätt att få ut sina tillgångar från kanalen.
Den mekanismen är ett Hash Timelock Contract (eller HTLC). Termen kan låta avskräckande, men är faktiskt ett ganska enkelt koncept att förstå. Den kombinerar två andra teknologier (hashlock och tidslock) för att åtgärda eventuellt osamarbetsvilligt beteende i betalningskanalerna.
Ett hashlock är ett villkor som ställs på en transaktion som dikterar att du bara kan spendera tillgångar genom att bevisa att du känner till en hemlighet. Avsändaren hashar en bit data och inkluderar hashen i transaktionen till mottagaren. Det enda sättet som mottagaren kan spendera det på är om hen tillhandahåller originaldata (hemligheten) som matchar hashen. Och det enda sättet som hen kan tillhandahålla den informationen på är om avsändaren ger ut denna information.
Ett tidslås är ett tillstånd som hindrar dig från att spendera tillgångar före en viss tid. Det anges antingen som en faktisk tid eller en specificerad blockhöjd.
HTLC:er skapas genom att kombinera hashlock och tidslock. I praktiken kan HTLC:er användas för att skapa villkorade betalningar – mottagaren måste tillhandahålla en hemlighet före en viss tidpunkt eller så kan avsändaren kräva tillbaka tillgångarna. Kommande del förklaras förmodligen bättre med ett exempel, så låt oss gå tillbaka till Alice och Bob.
Öppna och stänga kanaler
Vi såg exemplet med Alice och Bob som precis har skapat transaktioner som finansierar multisignatursadressen de kommer att dela. Men dessa transaktioner har inte publicerats till blockkedjan ännu! Vi måste göra en sak till först.
Tre coin från Bob och tre coin från Alice.
Kom ihåg att det enda sättet som dessa coin kan flytta ut ur multisignaturen är om både Alice och Bob tillsammans undertecknar en transaktion. Om Alice ville skicka alla sex coin till en extern adress skulle hon behöva Bobs godkännande. Hon skulle först sätta ihop en transaktion (sex bitcoin till den här adressen) och lägga till sin egen signatur.
Hon skulle kunna försöka skicka transaktionen direkt, men den skulle bli ogiltig eftersom Bob inte har inkluderat sin signatur. Alice måste ge honom den ofullständiga transaktionen först. När han väl lägger till sin signatur blir den giltig.
Vi har fortfarande inte infört en mekanism för att få alla att agera ärligt. Som vi sa tidigare – om din motpart vägrar att samarbeta, är dina tillgångar effektivt låsta. Låt oss gå in på mekanismen som förhindrar detta. Det finns några olika rörliga delar, så ha tålamod.
Varje part måste komma på en hemlighet – låt oss bara kalla dessa A och B. De skulle vara dåliga hemligheter om Alice och Bob avslöjade dem, så de håller dem dolda tills vidare. Paret genererar respektive hemligheters hash – h(A) och h(B). Så istället för att dela sina hemligheter, delar de dessa hashar med varandra.
Alice och Bob delar hashen från sina hemligheter med varandra.
Alice och Bob måste också skapa en uppsättning åtagandetransaktioner innan de publicerar sina första transaktioner till multisignatursadressen. Detta kommer att ge dem en lösning om den andra beslutar sig för att hålla tillgångarna som gisslan.
Om du tänker på en kanal som miniorderboken som vi hänvisade till tidigare, är åtagandetransaktioner de uppdateringar som du gör i orderboken. Varje gång du skapar ett nytt par åtagandetransaktioner flyttar du om tillgångarna mellan de två deltagarna.
Alices kommer att ha två utgångar – en som betalar en adress som hon äger och en annan som är låst till en ny multisignatursadress. Hon signerar den och ger den till Bob.
Alices transaktion med två utgångar – en till hennes egen adress och en till en ny multisignatur. Hon behöver fortfarande Bobs signatur för att göra så att den blir giltig.
Bob gör samma sak – en utgång betalar honom själv och den andra betalar en annan multisignatursadress. Han signerar den och ger den till Alice.
Vi har två ofullständiga transaktioner som är väldigt lika.
Normalt sett skulle Alice kunna lägga till en signatur till Bobs transaktion för att göra den giltig. Men dessa tillgångar spenderas från 2-av-2 multisignatur som vi inte har finansierat ännu. Det är lite som att försöka spendera en check från ett konto som har noll balans just nu. Därför kommer dessa delvis signerade transaktioner bara att kunna användas när multisignaturen är igång.
De nya multisignatursadresserna (där de 3 BTC-utgångarna är målet) har vissa speciella egenskaper. Låt oss ta en titt på den ofullständiga transaktionen som Alice undertecknade och gav till Bob. Multisignatursutgången kan användas under följande förhållanden:
Båda parter kan tillsammans underteckna den.
Bob kan spendera den själv efter en viss tid (på grund av vårt tidslås).
Alice kan spendera den om hon känner till Bobs hemliga B.
För transaktionen som Bob gav till Alice:
Båda parter kan tillsammans underteckna den.
Alice kan spendera den själv efter en viss tid.
Bob kan spendera den om han känner till Alices hemlighet A.
Tänk på att ingen av parterna känner till den andras hemlighet, så 3) är inte ett alternativ ännu. En annan sak att komma ihåg är att om du undertecknar en transaktion kan din motpart spendera den omedelbart, eftersom det inte finns några särskilda villkor för deras utgång. Du kan antingen vänta på att tidslåset löper ut för att spendera tillgångarna själv eller så kan du samarbeta med den andra parten för att spendera dem direkt.
Okej! Nu kan du publicera transaktionerna i den ursprungliga 2-av-2 multisignatursadressen. Det är äntligen säkert att göra detta, eftersom du kan hämta dina tillgångar om din motpart överger kanalen.
När transaktionerna har bekräftats är kanalen igång. Det första transaktionsparet visar oss det aktuella tillståndet för miniorderboken. För närvarande kommer den att betala ut 3 BTC till Bob och 3 BTC till Alice.
När Alice vill göra en ny betalning till Bob skapar paret två nya transaktioner för att ersätta den första uppsättningen. Saken är densamma – de är bara halvsignerade. Men Alice och Bob avslöjar först sina gamla hemligheter och byter ut nya hashar för nästa omgång av transaktioner.
Om Alice till exempel vill betala 1 BTC till Bob skulle de två nya transaktionerna kreditera 2 BTC till Alice och 4 BTC till Bob. På så sätt uppdateras balansen.
Båda parterna kan när som helst underteckna och sända en av de senaste transaktionerna för att "lösa in" den på blockkedjan. Men vilken part som än gör detta kommer att behöva vänta tills tidslåset har gått ut, medan den andra kan spendera direkt. Kom ihåg att om Bob signerar och sänder Alices transaktion har hon nu en utdata utan villkor.
Båda parter kan komma överens om att stänga kanalen tillsammans (en kooperativ stängning). Detta är förmodligen det enklaste och snabbaste sättet att få tillbaka dina tillgångar i kedjan. Men även om en part inte svarar eller vägrar att samarbeta kan den andra fortfarande kräva tillbaka sina tillgångar genom att vänta ut tidslåset.
Hur förhindrar Lightning-nätverket fusk?
Du kanske har identifierat en attackvektor här. Om Bob för närvarande har en balans på 1 BTC, vad hindrar honom då från att sända en äldre transaktion där han hade mer? Han har redan den halvsignerade transaktionen från Alice, så han behöver bara lägga till sin signatur och sända den, eller hur?
Ingenting hindrar honom från att göra detta – förutom det faktum att han kan förlora hela balansen. Låt oss säga att han sänder en gammal transaktion som betalar ett coin till Alice och fem till den multisignatursadressen som vi nämnde tidigare.
Alice får sitt coin omedelbart. Bob, å andra sidan, måste vänta tills tidslåset går ut för att spendera från multisignatursadressen. Kommer du ihåg det andra villkoret vi nämnde som skulle tillåta Alice att spendera samma tillgångar omedelbart? Hon behöver en hemlighet som hon inte hade just då. Det har hon nu – så fort den andra transaktionsomgången skapades avslöjade Bob hemligheten.
Medan Bob inte kan göra någonting medan han väntar på att tidslåset ska löpa ut kan Alice flytta dessa tillgångar. Denna bestraffningsbaserade mekanism innebär att det är osannolikt att deltagarna ens försöker fuska, eftersom kamraten kommer att få tillgång till dess coin.
Dirigera betalningar
Vi har berört detta tidigare – kanaler kan anslutas. Lightning-nätverket skulle inte vara så användbart för betalningar annars. Kommer du verkligen att låsa in 500 USD i en kanal med ett kafé, bara så att du kan få din dagliga kopp under de närmaste månaderna?
Det behöver du inte göra. Om Alice öppnar en kanal med Bob och Bob redan har en med Carol kan Bob dirigera betalningarna mellan de två. Detta kan fungera över flera "hopp", vilket innebär att Alice effektivt kan betala alla som har en väg till sig.
I det här scenariot kan Alice gå igenom flera vägar för att komma till Frank. I praktiken tar hon alltid den enklaste.
För sin roll i routingen kan mellanhänderna ta en liten avgift (även om det inte finns någon skyldighet att göra detta). Lightning-nätverket är fortfarande väldigt nytt, så en avgiftsmarknad har ännu inte realiserats. Det många förväntar sig att se är avgifter baserade på tillhandahållen likviditet.
På baskedjan baseras din avgift enbart på det utrymme som din transaktion tar upp i ett block – värdet som överförs spelar ingen roll – betalningar på 1 USD och 10 000 000 USD kostar alltså lika mycket. Däremot finns det inte något som heter blockutrymme inom Lightning-nätverket.
Istället pratar vi om lokala balanser och distansbalanser. Den lokala balansen är det belopp som du kan "skjuta vidare" till den andra änden av kanalen, medan distansbalansen är det som din motpart kan skjuta vidare till dig.
Dags för ett annat exempel. Låt oss ta en närmare titt på en av ovanstående vägar: Alice <> Carol <> Frank.
Användarnas balans före och efter en överföring av 0,3 BTC från Alice till Frank.
Alice <> Carol och Carol <> Frank har en total kapacitet på 1 BTC vardera. Alices lokala balans är 0,7 BTC. Om de avslutade detta på blockkedjan nu skulle hon få 0,7 BTC och Carol skulle få distansbalansen (dvs. 0,3 BTC).
Om Alice vill skicka 0,3 BTC till Frank, skjuter hon vidare 0,3 BTC till Carols sida av kanalen. Sedan skjuter Carol vidare 0,3 BTC från sin lokala balans i kanalen med Frank. Som ett resultat förblir Carols balans detsamma: +0,3 BTC från Alice och -0,3 BTC till Frank tar ut varandra.
Carol tappar inte i värde på att fungera som en koppling mellan Frank, men hon gör sig själv mindre flexibel. Som du ser kan hon nu spendera 0,6 BTC i sin kanal med Alice, men bara 0,1 BTC i kanalen med Frank.
Du kan föreställa dig en situation där Alice bara är ansluten till Carol, medan Frank är ansluten till ett mycket bredare nätverk. Carol kunde tidigare skicka totalt 0,4 BTC till andra via Frank, men nu kan hon bara skjuta vidare 0,1 BTC eftersom det är allt hon har i slutet av kanalen.
I det här scenariot tar Alice upp all Carols likviditet. Utan någon form av incitament kanske Carol inte skulle vilja försvaga sin egen position. Så istället kan hon bara säga att jag kommer att dirigera varje 0,01 BTC till en avgift på tio satoshis. Ju mer av Carols lokala balanser som hon offrar på "starkare" vägar, desto mer tjänar hon på detta sätt.
Som tidigare nämnts finns det inget faktiskt krav på att ta ut en avgift. Vissa kanske inte bryr sig om minskningen av likviditeten. Andra kanske bara öppnar kanaler direkt till mottagaren.
Begränsningar inom Lightning-nätverket
Det skulle vara fantastiskt om Lightning-nätverket visade sig vara lösningen på alla Bitcoins skalbarhetsproblem. Tyvärr har den sina egna brister som kan komma i vägen.
Användbarhet
Bitcoin är inte det mest intuitiva systemet för nybörjare – adresser, avgifter etcetera, kan vara förvirrande att bekanta sig med. Efter att en klient har konfigurerats måste användarna också börja med att öppna kanaler innan de kan börja göra betalningar. Detta kan vara en tidskrävande och överväldigande process för en nybörjare som introduceras för begrepp som inkommande/utgående kapacitet.
Ändå görs förbättringar ständigt för att minska hindren för inträde och för att ge användarna en mer strömlinjeformad upplevelse.
Likviditet
En av de största nackdelarna med Lightning-nätverket är att din förmåga att handla är begränsad. Du kan inte spendera mer än du har låst in på en kanal. Om du spenderar alla dina tillgångar så att distansbalansen har alla kanalens tillgångar, måste du stänga kanalen. Alternativt kan du vänta tills någon betalar dig genom den, men detta är inte idealiskt.
Dina vägar kan också begränsas av kanalens totala kapacitet. Ta Alice <> Carol <> Frank exempel från tidigare. Om Alice och Carol har en kapacitet på 5 BTC i sin kanal, men Carol och Frank bara har en kapacitet på 1 BTC, kan Alice aldrig skicka mer än 1 BTC. Även då skulle hela balansen behöva vara på Carols sida av Carol <> Frank-kanalen för att det ska fungera. Detta kan begränsa mängden tillgångar som kan skickas längs LN-kanaler avsevärt och har därmed en negativ effekt på användbarheten.
Centraliserade nav
På grund av problemet som nämndes i föregående avsnitt finns det en viss oro för att nätverket underlättar för skapandet av massiva "nav". Det vill säga stora, tungt sammankopplade enheter med massor av likviditet. Alla betydande betalningar skulle behöva dirigeras genom några av dessa enheter.
Självklart skulle detta inte vara en bra situation. Det skulle försvaga systemet, eftersom dessa enheter som går offline i hög grad skulle störa relationerna mellan personerna. Det finns också en ökad risk för censur, eftersom det bara finns några få punkter genom vilka transaktionerna flyter.
Det aktuella tillståndet för Lightning-nätverket
I skrivande stund i april 2020 ser Lightning-nätverket friskt ut. Det har uppåt 12 000 onlinenoder, drygt 30 000 aktiva kanaler och drygt 920 BTC i kapacitet.
Global distribution av Lightning-nätverksnoder.
Det finns en handfull olika nodimplementeringar – Blockstreams c-lightning, Lightning Labs Lightning-nätverk Daemon och ACINQ:s Eclair är några av de mest populära. För användare som är mindre tekniskt kunniga erbjuder många företag plug-and-play-noder. Det enda du behöver göra med dessa är att slå på enheten, så är du redo att komma igång med Lightning-nätverket.
Sammanfattningsvis
Sedan huvudnät-lanseringen 2018 har Lightning Nätverk haft en betydande tillväxt. Det finns fortfarande några hinder att övervinna, eftersom det för närvarande kräver en viss grad av teknisk kompetens för att driva en Lightning-nod. Men med den mängd utveckling som äger rum kan vi mycket väl se hindren för inträde minska efter hand.
Mer information
Ansvarsfriskrivning: Detta innehåll presenteras för dig ”i befintligt skick" och avser allmän information och information för utbildningsändamål, utan representation eller garantier av något slag. Det ska inte tolkas som ekonomisk, juridisk eller annan professionell rådgivning, och är inte heller avsett att rekommendera köp av någon specifik produkt eller tjänst. Du bör söka egna råd från lämpliga professionella rådgivare. Om det till artikeln har bidragits av en tredje parts bidragsgivare, ska det observeras att de åsikter som uttrycks tillhör tredjepartsbidragsgivaren och inte nödvändigtvis återspeglar Binance Academys åsikter. Läs vår fullständiga ansvarsfriskrivning här för mer information. Priserna på digitala tillgångar kan vara volatila. Värdet på din investering kan gå ner eller upp och du kanske inte får tillbaka det investerade beloppet. Du är ensam ansvarig för dina investeringsbeslut och Binance Academy ansvarar inte för eventuella förluster du kan drabbas av. Detta material ska inte tolkas som ekonomisk, juridisk eller annan professionell rådgivning. För mer information, se våra användarvillkor och vår riskvarning.