Core Lightning: Hur Blockstreams implementeringsrebrand talar till sin långsiktiga vision för Bitcoin

Nu kallad Core Lightning, Blockstreams Lightning Network-implementering strävar efter att vara Bitcoins interoperabla, specifikationsfokuserade standard.

Bitcoin-infrastrukturföretaget Blockstream bytte nyligen om sin Lightning Network-implementering från c-lightning till Core Lightning (CLN) i ett försök att lyfta fram projektets långsiktiga fokus på interoperabilitet och specifikationsarbete.

Det ursprungliga namnet, som anspelade på programmeringsspråket C som implementeringen är inbyggd i, återspeglade inte företagets faktiska avsikt med projektet. Nu försöker Core Lightning återspegla Blockstream-implementeringens värdeförslag.

"Vi hoppas att det förnyade namnet bättre kommunicerar CLN:s fokus på interoperabilitet, specifikationsarbete och det pågående målet att tillhandahålla en referensimplementering med prioritet på korrekthet och robusthet," sa företaget i en meddelandet.

Varför finns det olika implementeringar av Lightning Network?

Lightning Network är ett abstrakt koncept av vad som i själva verket är många olika Lightning-kanaler som är sammankopplade. Lightning-betalningskanaler lägger grunden för nätverket eftersom två deltagare låser upp en mängd bitcoin på Bitcoin-nätverkets baslager för att göra snabba och billiga betalningar utanför kedjan sinsemellan. Men genom att öppna fler kanaler med olika deltagare kan betalningar sedan dirigeras i detta "mesh-nätverk", från en deltagare till nästa tills en slutlig mottagare av en Lightning-betalning hittas.

Därför är abstraktionen som är "Lightning-nätverket” kräver att olika deltagare kommunicerar med varandra så att de kan dirigera varandras betalningar och möjliggöra friktionsfri interaktion. Denna kommunikation sker mellan noder som kör Lightning-protokollmjukvaran och som därför bland annat kan skicka och ta emot betalningar.

Medan i Bitcoin finns det för närvarande en de-facto standard nodmjukvara, Bitcoin Core, det finns mer än en typ av Lightning-nodprogramvara som för närvarande är populär. Som ett resultat finns det ett behov av en uppsättning dokument för att diktera hur dessa olika typer av Lightning-noder - aka "implementationer" - kan prata med varandra.

Smakämnen Dokument på grund av Lightning Technology (BOLT). definiera uppsättningen specifikationer som alla Lightning-nodimplementeringar måste följa för att vara en stabil, kompatibel deltagare i Lightning-nätverket. Det finns för närvarande 11 BOLT-dokument som beskriver allt från hur man etablerar en betalningskanal och finansierar den med bitcoin till hur man ska begära en Lightning-betalning.

Naturligtvis innebär det faktum att det finns olika Lightning-implementationer också att det finns olika erbjudanden tillgängliga för användare, och de kan välja vilken programvara som helst att köra baserat på deras specifika behov. På en hög nivå finns det fyra stora Lightning-implementeringar, LND, Core Lightning, Eclair och LDK, var och en inriktad på specifika användningsfall.

Core Lightning: Byggd av BOLT

CLN, tidigare c-lightning, har varit i produktionsanvändning på Bitcoin mainnet sedan början av 2018. Skrivet i programmeringsspråket C, som erbjuder utvecklare en hög grad av kontroll över beteendet hos sin kod även på en låg nivå, CLN har ett fokus på effektivitet samt på att förse utvecklare och användare med en modulär, plugin-baserad implementering av Bitcoins skalningsprotokoll för lager 2.

"Vi strävar efter att vara en högpresterande, företagsklassad, spec-kompatibel implementering," berättade Lightning-utvecklare på Blockstream, Rusty Russel, Bitcoin Magazine. "Det betyder traditionellt att vi är mer för avancerade användare, företag och utvecklare att bygga på."

CLN fungerar bara på Linux och MacOS, och kräver en lokal eller fjärrkontroll bitcoind version 0.16 eller senare som är helt ikapp det nätverk som användaren kör på och vidarebefordrar transaktioner från. Beskärning är delvis stöds.

Som en lätt implementering möjliggör CLN en stor nivå av anpassning eftersom det tillåter användaren att göra det till sin egen och bara lägga till de funktioner de vill ha eller behöver. Utvecklare kan samverka med demonen genom anpassade JSON-RPC-metoder, så att de effektivt kan anpassa funktionaliteten efter sina behov genom plugins som kan komma åt detaljer på låg nivå direkt.

CLN:s modularitet, effektivitet och kod robusthet kommer också med sina medföljande nackdelar. Christian Decker, en forskare på Blockstream fokuserade på skalningslösningar för Bitcoin, sade under London Bitcoin Devs-mötet förra månaden att, genom att hålla fast vid UNIX-filosofin att göra en sak väldigt bra och inte tvinga användaren beslut, kommer CLN på ett "bara ben" sätt och kräver visst engagemang från användaren för att få det att fungera .

Noterbart är att Blockstreams implementering fokuserar mycket på specifikationsprocessen och genererar mycket av sin kod direkt från BOLT-specifikationerna, enligt Russel. Även om detta säkerställer en helt spec-kompatibel implementering, har teamet mindre tid att marknadsföra sitt arbete och identifierar detta som anledningen till att de ser mindre communityengagemang och nodandel än andra implementeringar.

"Vi är byggda utifrån Lightning BOLT-specifikationerna, bokstavligen!" Russel berättade Bitcoin Magazine. "Detta betyder att vi bryr oss mycket (och, som ett team, har lagt ner en enorm ansträngning) på att koordinera arkitekturen för hela Lightning Network via BOLT-specifikationerna."

Teamet föreslår vanligtvis en ny specifikation för det bredare utvecklingssamhället innan det läggs till i CLN i ett försök att säkerställa långsiktig kompatibilitet mellan olika implementeringar samtidigt som de begär fler ögon att granska, testa och kommentera dess kod innan den så småningom förvandlas till en ny BOLT och blir redo att antas av alla implementeringar.

"En del av anledningen till att vi gör spec-and-review-across-implementations-processen är att den hjälper till att identifiera bättre sätt att göra saker på - hitta buggar, identifiera framtida problem," berättade Lisa Neigut, Lightning-protokollingenjör på Blockstream. Bitcoin Magazine.

Med tanke på dess effektivitet och lätta fotavtryck är CLN troligen den bäst lämpade implementeringen för enheter med låg specifikation.

Blockstreams team har också utvecklat en uppsättning nya funktioner som utökar BOLTs nuvarande funktionalitet, som ofta är utkast till specifikationer eller specifikationsförslag, inklusive samarbetskanalöppningar, likviditetsannonser och BOLT 12. CLN ger användaren möjlighet att prova dessa kommande specifikationer.

"Vi tar bort dragdelar av Lightning-specifikationen under experimentella alternativ," berättade Russel Bitcoin Magazine. "Men om du är mer äventyrlig ger de experimentella alternativen dig en

inblick i vad som kommer till Lightning Network härnäst!”

Samarbetskanal öppnas, tidigare kallad "dubbla finansieringskanaler", gör det möjligt för deltagare att tillsammans öppna en ny kanal genom att gemensamt finansiera kanalfinansieringstransaktionen. För närvarande är kanaler öppna med en ensidig finansieringstransaktion av en deltagare. Samarbetskanalöppningar möjliggör också distribuerade CoinJoins till en Lightning-kanal öppen.

"Du kan orkestrera din egen CoinJoin med ett gäng andra Lightning-noder," sa Neigut Bitcoin Magazine. "Du gör det decentraliserat så att de enda som vet vem som är inblandade i det är de som faktiskt är en del av den transaktionen, så det finns ingen central koordinator som får det att hända."

Likviditetsannonser utnyttjar också samarbetskanalöppningar. Enligt en Blockstream blogginlägg, "de är ett lättviktigt sätt att tillhandahålla möjligheten att samordna likviditetsdistributionen över nätverket på ett decentraliserat och tillgängligt sätt."

Funktionen försöker lösa ett vanligt problem i Lightning: inkommande likviditet.

Likviditetsannonser låter dig "se alla människor som annonserar att de kommer att sälja inkommande likviditet till dig om du öppnar en kanal för dem, vilket är riktigt spännande grejer," sa Neigut.

BOLT 12 är ett annat utkast till specifikation för Lightning-plånböcker och noder med experimentellt stöd i CLN. Den föreslagna funktionen, myntade "erbjudanden", skulle förbättra BOLT 11-fakturor genom att möjliggöra återanvändbara erbjudanden, medan en BOLT 11-faktura bara kan användas en gång. Dessutom, medan en faktura uteslutande är en betalningsförfrågan, kan du använda ett erbjudande för att även skicka, inte bara ta emot, pengar.

CLN-användare kan nu också automatisera sina nodhanteringsuppgifter med CLBOSS, ett nyligen släppt "artificiell intelligens"-verktyg som kan bestämma vilka noder som ska öppnas kanaler till, öppna kanaler när avgifterna är låga och det finns on-chain-fonder, justera routingavgifter för att vara konkurrenskraftiga med andra noder, utföra ubåtsbyten via boltz .exchange API och automatiskt ombalansera kanaler.

Även om olika implementeringar bör uppmuntras att sträva efter fristående lösningar för sina specifika användningsfall samtidigt som de följer de nuvarande BOLT 11-specifikationerna, är det generellt sett god praxis att lägga fram ett medföljande specifikationsförslag för att hjälpa andra implementeringar att använda samma – eller en liknande – funktion. ett drag förmodas tillgodose de långsiktiga intressena för Lightnings breda och ständigt växande användarbas. Med det sagt är spec-processen inte en lätt uppgift att uthärda.

”Som process är det mödosamt och tar mycket tid. Det kräver samordning med andra människor med många olika perspektiv, säger Neigut.

Som ett resultat av detta ägnar olika företag olika mycket tid och kraft åt denna process beroende på deras individuella prioriteringar, som naturligtvis skiljer sig åt. Medan, enligt Russel, CLN-teamet har spenderat det mesta av sin "ansträngning på specifikationer och implementeringsdetaljer på låg nivå och nästan ingen ansträngning på utvecklare uppsökande eller marknadsföring", har Lightning Labs, företaget bakom LND, ofta valt att fokusera mer tekniska resurser på nya funktioner och lösa kunders problem än på den mödosamma spec-processen.

LND: Luckor som CLN kan fylla?

LND är en utvecklare-första Lightning-implementation som fokuserar på att underlätta utvecklingen av applikationer ovanpå den, och därigenom lägger stor vikt vid utvecklarinteraktion, särskilt i en standardmetod för kommunikation genom REST API:er, som möjliggör enklare apputveckling, förutom att tillhandahålla tydlig dokumentation och en enkel installationsupplevelse.

"Vi vill att utvecklare ska kunna plocka upp det enkelt, integrera det i sin produkt, bygga appar ovanpå det och distribuera det som en plånbok eller en egen värd nod," LND-utvecklare Oliver Gugger sade på London Bitcoin Devs meetup. "Ta med det till plebs."

Som ett resultat fokuserar LND på att "ha ett bra utvecklargränssnitt", tillade Gugger, genom att aktivera gRPC och REST.

"LND har en fantastisk community, enkel installation och bra utvecklardokumentation," sa Russel på frågan varför han trodde att LND är den mest populära Lightning-implementeringen.

LND har sett det största samhällsengagemanget bland alla implementeringar och driver för närvarande majoriteten av alla nätverksnoder. Några uppskattningar placera LND:s andel av totala publika Lightning-noder någonstans mellan 70 % och 90 %.

LND har också det som utan tvekan är det största utvecklingsteamet på heltid. Som ett resultat har teamet lyckats bygga upp en uppsjö av värdeadderande tjänster kring LND, som t.ex. Aperture och likviditetstjänsterna Lightning loop och Pool.

Loop använder ubåtsbyten för att överbrygga bitcoin på kedja och utanför kedjan, vilket gör det enkelt att flytta bitcoin in i och ut ur Lightning Network. Den utför automatiserad kanalbalansering, integritetsswappar utan förvaring, avgiftsbesparande opportunistisk transaktionsbatchning och framstegsövervakning av byten under flygning.

Pool är en peer-to-peer-marknadsplats för Lightning-kanaler. Den kopplar samman användare som behöver tillgång till inkommande likviditet med de som har kapital att distribuera på Lightning Network genom att göra det möjligt för en Lightning Network-deltagare att signalera ett behov av det och uppmuntra andra att öppna kanaler med dem genom att använda sitt kapital.

Med LNDs fokus vanligtvis på nya funktioner och kundsupport, har CLN-teamet hittat en lucka på marknaden som de hoppas kunna fylla genom att ägna mer uppmärksamhet åt specifikationsprocessen.

Till Spec Eller Inte Till Spec

"Labs-teamet har kommit på fantastiska saker," sa Neigut. "De har bara, som organisation, inte varit fantastiska när det gäller att skriva specifikationer för de saker som de lägger till. Ett bra exempel på det är KeySend.”

KeySend tillåter en Lightning-nod att skicka en Lightning-betalning till någon som endast har den mottagande nodens ID, vilket innebär att verktyget inte kräver fakturor, vilket är det aktuella de facto standard på Lightnings betalningsmekanism.

"De lanserade det, många började använda det, men de specificerade det aldrig helt," tillade Neigut. "Så CLN ville kunna stödja det. En av våra teammedlemmar var tvungen att gå tillbaka och ta reda på hur man fick det att fungera bara genom att läsa deras kod och omvända den.”

En spec skrevs så småningom av Spirals Lightning-implementering, LDK, påminde Neigut om, efter att dess team omvänt utvecklat Lightning Labs kod.

"Och de andra teamen behövde bara följa med eftersom LND har en så stor installationsbas", sa hon. "Det är inte som den mest samarbetande processen."

"Teamet av människor som arbetar med Lightning Labs grejer är ganska solida," tillade Neigut. "Jag tror bara att de utnyttjar sin nätverksdominans för att inte behöva göra allt det här extraarbetet för om de inte gör det kommer någon annan att göra det eftersom majoriteten av noderna i nätverket kör sin kod."

Neigut sa att hon redan är van vid att LND är i rampljuset och är "standard Lightning"-implementeringen - något hon erkänner att hon tycker om som utvecklare på grund av de färre kundsupportkraven hon får.

"Men jag tror att vi skulle få en sundare nätverksdynamik om det inte fanns någon majoritetsimplementering," tillade hon. "Jag tror att det verkligen skulle förändra spelet när det gäller mängden samarbete som alla måste göra för att få sina grejer skickade på Lightning. Och det skulle vara hälsosamt.”

Noggrann uppmärksamhet på specifikationer är utan tvekan central för utveckling av öppen källkod i en öppen nätverksmiljö. På Lightning utgör sådana specifikationer grunden för protokollet och säkerställer interoperabiliteten för de olika versionerna som deltar i nätverket.

Men även om vissa hävdar att stora förändringar och nya tillägg till en Lightning-implementering bör ha en åtföljande specifikation, kan andra se BOLT-specifikationerna som ett absolut minimum, ovanpå vilket varje implementering kan bygga sina egna spännande nya funktioner - som inte nödvändigtvis behöver portas tillbaka till spec-sviten.

"Dess hård skapa ett infrastrukturföretag med öppen källkod, så det är inte förvånande att jag inte håller med om alla [Lightning Labs] prioriteringar”, sa Russel. "Jag tror verkligen att de kommer att hitta ett sätt att både skapa en hållbar inkomstström och vara en pålitlig partner i den tekniska utvecklingen av Lightning Network; Jag tror inte att någon vill se nätverket delas i bitar.”

Att helt ignorera spec-processen kan leda till uppkomsten av vitt skilda sub-ekosystem, vilket kan skada utvecklingen och adoptionen av Lightning Network som helhet om de skulle bli icke-kompatibla. Men som Russel betonade finns det inget som tyder på att någon implementering gör det idag. Att upprätthålla en sammanhållen, interoperabel interaktion mellan noder är nyckeln om vi vill hålla implementeringsdetaljer borta från användaren och därigenom möjliggöra en bra användarupplevelse.

"Om [Lightning Labs] var ledande och de också var ledande inom specifikationer, tror jag att det skulle bli lite mindre friktion kring att lägga till nya funktioner, eftersom det inte skulle vara lika svårt att följa vad de gör, sa Neigut. "Kanske kommer de att vara mer involverade i spec-processen framöver. Jag tror att de definitivt har fått feedback från oss och resten av samhället om att specifikationsprocessen är viktig.”

En del av kontroversen och spänningar i BOLT-specifikationen härstamma från ett mail delade på Twitter i slutet av februari, där chefen för Lightning-likviditet på Lightning Labs, Alex Bosworth, kommenterade BOLT 12 och BOLT-specifikationen.

Bosworth skrev att BOLT-processen är en godtycklig standardiseringsprocess som inte kräver människors samtycke och därför representerar "mer av en åsiktsfull uppsättning dokument som kontrolleras av en godtycklig process än det är ett fördrag mellan oberoende implementeringar."

Lightning Labs senare klar att Bosworths kommentarer endast återspeglar hans åsikter och inte nödvändigtvis företagets.

Decker delade med sig av sina tankar om Bosworths kommentarer och om BOLT-specifikationsprocessen under London Bitcoin Devs-mötet.

"Jag tror att det är mycket starka uttalanden från någon som aldrig har deltagit i ett enda spec-möte," sa han. "Det finns lite tvist i spec-processen men det är designat. Om en implementering kunde diktera hur hela nätverket ser ut, skulle vi sluta med en mycket närsynt bild av vad nätverket skulle kunna vara och vi skulle inte kunna betjäna alla de olika användningsfallen som vi betjänar.”

"Och så ja, ibland är spec-processen frustrerande, jag håller helt med om det," tillade han. ”Vi har verkligen olika syn på hur nätverket ska se ut. Men genom denna tes, antites och syntesprocess kommer vi fram till ett system som är mycket mer kapabelt att tjäna våra användare än om en implementering skulle göra det ensam.”

"Jag personligen arbetar inte med specen så jag känner mig inte kvalificerad att ge ett svar," sa Gugger vid mötet och kommenterade Bosworths e-post. "Jag ville bara tillägga att jag inte nödvändigtvis håller med om alla punkter som Alex nämnde. Jag skulle definitivt ha sagt det på ett annat sätt också. Jag tror att brist på resurser för att arbeta med specen ibland tolkas som att vi blockerar saker vilket inte är avsikten och inte vårt mål förstås. Vi vill lägga ner mer arbete på specen så jag hoppas att vi kommer att förbättra oss där. Det är en intressant sak att observera, hur den frustrationen ibland kommer upp till ytan. Tack [Decker och ACINQ-utvecklaren Bastien Teinturier] för allt arbete du gör med specen. Jag måste ta upp också så jag ska göra mitt bästa.”

Russel kommenterade också Bosworths mejl i en Twitter-tråden där han lovade att lägga mer tid på att polera och marknadsföra CLN, eftersom han sa att LND inte implementerade Lightning först och inte implementerade det bäst – även om dess community är fantastiskt, tillade han.

"Det visar sig att de har bestämt sig för att de kan utnyttja nätverksdominans till protokollkontroll, och specsprocessen är inte "riktig", skrev han i tråden. "Lightning Labs har gjort anspråk på ägande av Lightning-nätverket på många sätt: jag har varit ovillig att kalla ut dem offentligt. Men blixtnätverket och gemenskapen förtjänar bättre.”

Russel svarade inte på frågor från Bitcoin Magazine hänvisar till denna tråd. Lightning Labs avböjde att kommentera.

"Tillbaka 2016 kom vi från tre olika håll och bestämde oss för att sammanfoga alla de saker som vi lärde oss under den här första experimentfasen i en enda specifikation så att vi kunde samarbeta och samarbeta", sa Decker vid mötet. ”Denna experimentella fas måste alltid följas upp av ett förslag som är inåtblickbart av alla andra och kan genomföras av alla andra. Ibland saknas det formella förslaget och det hindrar andra implementeringar från att ge sin egen recension av den funktionen. Den här recensionen är väldigt viktig för att se till att den fungerar för alla och att det är det bästa vi kan göra det.”

"Som namnet Lightning Network antyder, tjänar det mycket på nätverkseffekterna vi får genom att vara kompatibla, genom att kunna samverka och göra det möjligt för alla implementeringar att spela på lika villkor", tillade han senare.

Implementeringar kompletterar varandra, de konkurrerar inte

Förutom den mycket specifika kontroversen angående specifikationsprocessen, fungerar Lightning-implementeringar mestadels separat och sedan tillsammans för att få de bästa och mest efterfrågade funktionerna till nätverket, vilket säkerställer en övergripande bättre användarupplevelse.

Som ett resultat kommer Blockstreams drag att driva CLN som ett spec-kompatibelt, modulärt och lätt erbjudande som ett alternativ för dem som är intresserade av att köra en nodimplementering som strävar efter att vara helt interoperabel med resten av nätverket och ger en unik uppsättning förmåner till dem som gör det.

Eftersom olika implementeringar strävar efter att bli deras bästa version och tillgodose ett specifikt användningsfall genom att utforska sina egna värdeförslag, är det i slutändan användaren som kommer att dra nytta av allt eftersom fler och bättre alternativ dyker upp.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://bitcoinmagazine.com/technical/blockstream-core-lightning-bitcoin-rebrand