Core Lightning: Hvordan Blockstreams implementering Rebrand snakker til sin langsiktige visjon for Bitcoin PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Core Lightning: Hvordan Blockstreams implementeringsrebrand snakker til sin langsiktige visjon for Bitcoin

Nå kalt Core Lightning, søker Blockstreams Lightning Network-implementering å være Bitcoins interoperable, spesifikasjonsfokuserte standard.

Bitcoin-infrastrukturselskapet Blockstream endret nylig sin Lightning Network-implementering fra c-lightning til Core Lightning (CLN) i et forsøk på å fremheve prosjektets langsiktige fokus på interoperabilitet og spesifikasjonsarbeid.

Det opprinnelige navnet, som refererte til C-programmeringsspråket implementeringen er bygget i, reflekterte ikke selskapets faktiske intensjoner med prosjektet. Nå søker Core Lightning å reflektere Blockstream-implementeringens verdiforslag.

"Vi håper det fornyede navnet bedre kommuniserer CLNs fokus på interoperabilitet, spesifikasjonsarbeid og det pågående målet om å gi en referanseimplementering med prioritet på korrekthet og robusthet," sa selskapet i en uttalelse.

Hvorfor er det forskjellige implementeringer av Lightning Network?

The Lightning Network er et abstrakt konsept av det som faktisk er mange forskjellige Lightning-kanaler koblet sammen. Lynbetalingskanaler legger grunnlaget for nettverket da to deltakere låser opp en mengde bitcoin på Bitcoin-nettverkets basislag for å foreta raske og billige betalinger utenfor kjeden seg imellom. Men ved å åpne flere kanaler med forskjellige deltakere, kan betalinger deretter rutes i dette "mesh-nettverket", fra en deltaker til den neste til en endelig mottaker av en Lightning-betaling er funnet.

Derfor er abstraksjonen som er "Lightning-nettverket” krever at forskjellige deltakere kommuniserer med hverandre slik at de kan rute hverandres betalinger og muliggjøre friksjonsfri interaksjon. Denne kommunikasjonen skjer mellom noder som kjører Lightning-protokollprogramvaren og som derfor blant annet kan sende og motta betalinger.

Mens det i Bitcoin for tiden er en de-facto standard nodeprogramvare, Bitcoin Core, er det mer enn én type Lightning-nodeprogramvare som er populær for øyeblikket. Som et resultat er det behov for et sett med dokumenter for å diktere hvordan disse forskjellige typene Lightning-noder - aka "implementeringer" - kan snakke med hverandre.

De Dokumenter med basis for lynteknologi (BOLT). definere settet med spesifikasjoner som alle Lightning-nodeimplementeringer må overholde for å være en stabil, kompatibel deltaker i Lightning Network. Det er for tiden 11 BOLT-dokumenter som beskriver alt fra hvordan man etablerer en betalingskanal og finansierer den med bitcoin til hvordan man bør be om en Lightning-betaling.

Naturligvis betyr det at det er forskjellige Lightning-implementeringer også at det er forskjellige tilbud tilgjengelig for brukere, og de kan velge hvilken programvare som skal kjøres basert på deres spesifikke behov. På et høyt nivå er det fire store Lightning-implementeringer, LND, Core Lightning, Eclair og LDK, hver rettet mot spesifikke brukstilfeller.

Core Lightning: Bygget fra BOLT

CLN, tidligere c-lightning, har vært i produksjonsbruk på Bitcoin mainnet siden tidlig i 2018. Skrevet i programmeringsspråket C, som gir utviklere en høy grad av kontroll over oppførselen til koden deres selv på et lavt nivå, har CLN et fokus på effektivitet så vel som på å gi utviklere og brukere en modulær, plugin-basert implementering av Bitcoins Layer 2-skaleringsprotokoll.

"Vi har som mål å være en høyytelses, enterprise-grade, spesifikasjonskompatibel implementering," fortalte Lightning-utvikler hos Blockstream, Rusty Russel, Bitcoin Magazine. "Det betyr tradisjonelt at vi er mer for avanserte brukere, bedrifter og utviklere å bygge på toppen av."

CLN fungerer bare på Linux og MacOS, og krever en lokal eller fjernkontroll bitcoind versjon 0.16 eller nyere som er fullstendig fanget opp med nettverket som brukeren kjører på og videresender transaksjoner fra. Beskjæring er delvis støttet.

Som en lett implementering, muliggjør CLN et stort nivå av tilpasning ettersom det lar brukeren gjøre det til sitt eget og bare legge til funksjonene de ønsker eller trenger. Utviklere kan grensesnitt med daemonen gjennom tilpassede JSON-RPC-metoder, slik at de effektivt kan tilpasse funksjonaliteten til deres behov gjennom plugins som kan få direkte tilgang til detaljer på lavt nivå.

CLNs modularitet, effektivitet og koderobusthet kommer også med sine medfølgende ulemper. Christian Decker, en forsker ved Blockstream fokuserte på skaleringsløsninger for Bitcoin, sa under London Bitcoin Devs-møtet forrige måned at ved å følge UNIX-filosofien om å gjøre én ting veldig bra og ikke tvinge beslutninger på brukeren, kommer CLN på en "bare bein" måte og krever en viss dedikasjon fra brukeren for å få det til å fungere .

Spesielt fokuserer Blockstreams implementering sterkt på spesifikasjonsprosessen og genererer mye av koden direkte fra BOLT-spesifikasjonene, ifølge Russel. Selv om dette sikrer en fullstendig spesifikasjonskompatibel implementering, har teamet mindre tid til å markedsføre arbeidet sitt og identifiserer dette som grunnen til at det ser mindre fellesskapsengasjement og nodeandel enn andre implementeringer.

"Vi er bygget fra Lightning BOLT-spesifikasjonene, bokstavelig talt!" Russel fortalte Bitcoin Magazine. "Dette betyr at vi bryr oss mye (og, som et team, har lagt ned en enorm innsats) for å koordinere arkitekturen til hele Lightning Network via BOLT-spesifikasjonene."

Teamet foreslår vanligvis en ny spesifikasjon til det bredere utviklingsfellesskapet før de legger den til CLN i et forsøk på å sikre langsiktig kompatibilitet mellom forskjellige implementeringer samtidig som de ber om flere øyne til å gjennomgå, teste og kommentere koden før den til slutt blir omgjort til en ny BOLT og blir klar til å bli adoptert av alle implementeringer.

"Noe av grunnen til at vi gjør prosessen med spesifikasjoner og gjennomgang på tvers av implementeringer, er at den hjelper til med å identifisere bedre måter å gjøre ting på - finne feil, identifisere fremtidige problemer," sa Lisa Neigut, Lightning-protokollingeniør hos Blockstream. Bitcoin Magazine.

Gitt sin effektivitet og lette fotavtrykk, er CLN sannsynligvis den best egnede implementeringen for enheter med lav spesifikasjon.

Blockstreams team har også utviklet et sett med nye funksjoner som utvider BOLTs nåværende funksjonalitet, som ofte er utkast til spesifikasjoner eller spesifikasjonsforslag, inkludert samarbeidskanalåpninger, likviditetsannonser og BOLT 12. CLN gir brukeren muligheten til å prøve ut disse kommende spesifikasjonene.

"Vi fjerner utkast til Lightning-spesifikasjonen under eksperimentelle alternativer," fortalte Russel Bitcoin Magazine. "Men hvis du er mer eventyrlysten, gir de eksperimentelle alternativene deg en

innsikt i hva som kommer til Lightning Network neste gang!»

Samarbeidskanal åpnes, tidligere kalt "doble finansieringskanaler", gjør det mulig for deltakere å åpne en ny kanal i samarbeid ved å i fellesskap finansierer kanalfinansieringstransaksjonen. Foreløpig er kanaler åpne med en ensidig finansieringstransaksjon av én deltaker. Samarbeidskanal åpner også muliggjør distribuerte CoinJoins til en Lightning-kanal åpen.

"Du kan orkestrere din egen CoinJoin med en haug med andre Lightning-noder," fortalte Neigut Bitcoin Magazine. "Du gjør det desentralisert, så de eneste som vet om hvem som er involvert i det er personene som faktisk er en del av den transaksjonen, så det er ingen sentral koordinator som får det til å skje."

Likviditetsannonser utnytter også samarbeidskanalåpninger. Ifølge en Blockstream blogginnlegg, "de er en lett måte å gi muligheten til å koordinere likviditetsdistribusjon på tvers av nettverket på en desentralisert og tilgjengelig måte."

Funksjonen forsøker å løse et vanlig problem i Lightning: inngående likviditet.

Likviditetsannonser lar deg "se alle folk som annonserer at de vil selge deg inngående likviditet hvis du åpner en kanal for dem, noe som er veldig spennende ting," sa Neigut.

BOLT 12 er et annet utkast til spesifikasjoner for Lightning-lommebøker og noder med eksperimentell støtte i CLN. Den foreslåtte funksjonen, laget "tilbud", vil forbedre BOLT 11-fakturaer ved å aktivere gjenbrukbare tilbud, mens en BOLT 11-faktura bare kan brukes én gang. Videre, mens en faktura utelukkende er en betalingsforespørsel, kan du bruke et tilbud til også å sende, ikke bare motta, penger.

CLN-brukere kan nå også automatisere nodeadministrasjonsoppgavene sine med CLBOSS, et nylig utgitt "kunstig intelligens"-verktøy som kan bestemme hvilke noder som skal åpnes kanaler til, åpne kanaler når avgiftene er lave og det er kjedefond, justere ruteavgiftene for å være konkurransedyktige med andre noder, utføre ubåtbytte via boltz .exchange API og automatisk rebalansere kanaler.

Selv om forskjellige implementeringer bør oppmuntres til å forfølge frittstående løsninger for deres spesifikke brukstilfeller mens de overholder gjeldende BOLT 11-spesifikasjoner, er det generelt god praksis å legge frem et medfølgende spesifikasjonsforslag for å hjelpe andre implementeringer med å implementere den samme – eller en lignende – funksjon. et trekk ivaretar visstnok de langsiktige interessene til Lightnings brede og stadig voksende brukerbase. Når det er sagt, er ikke spesifikasjonsprosessen en lett oppgave å tåle.

«Som en prosess er det krevende og tar mye tid. Det krever koordinering med andre mennesker med mange forskjellige perspektiver, sa Neigut.

Som et resultat dedikerer forskjellige selskaper forskjellig tid og krefter til denne prosessen i henhold til deres individuelle prioriteringer, som naturligvis er forskjellige. Mens, ifølge Russel, CLN-teamet har brukt mesteparten av sin "innsats på spesifikasjonene og implementeringsdetaljer på lavt nivå og nesten ingen innsats på utvikleroppsøking eller markedsføring," har Lightning Labs, selskapet bak LND, ofte valgt å fokusere mer ingeniørressurser på nye funksjoner og løsning av kundenes smertepunkter enn på den krevende spesifikasjonsprosessen.

LND: Gap CLN kan fylle?

LND er en utvikler-første Lightning-implementering som fokuserer på å legge til rette for utvikling av applikasjoner på toppen av den, og legger dermed sterk vekt på utviklerinteraksjon, spesielt i en standard tilnærming til kommunikasjon gjennom REST APIer, som muliggjør enklere apputvikling, i tillegg til å tilby tydelig dokumentasjon og en enkel oppsettopplevelse.

"Vi vil at utviklere skal kunne plukke det opp enkelt, integrere det i produktet sitt, bygge apper på toppen av det og distribuere det som en lommebok eller en selvhostet node," LND-utvikler Oliver Gugger sa på London Bitcoin Devs-treffet. "Bringer det til plebs."

Som et resultat fokuserer LND på "å ha et flott utviklergrensesnitt," la Gugger til, ved å aktivere gRPC og REST.

"LND har et flott fellesskap, enkelt oppsett og flott utviklerdokumentasjon," sa Russel på spørsmål om hvorfor han trodde LND er den mest populære Lightning-implementeringen.

LND har sett det største samfunnsengasjementet blant alle implementeringer og driver for tiden flertallet av alle nettverksnoder. Noen estimater sette LNDs andel av totale offentlige Lightning-noder hvor som helst mellom 70 % og 90 %.

LND kan også skryte av det som uten tvil er det største utviklingsteamet på heltid. Som et resultat har teamet klart å bygge en mengde verdiøkende tjenester rundt LND, som f.eks. Aperture og likviditetstjenestene Lightning Loop og Basseng.

Loop bruker ubåtbytte for å bygge bro mellom kjede og utenfor kjede bitcoin, noe som gjør det enkelt å flytte bitcoin inn og ut av Lightning Network. Den utfører automatisert kanalbalansering, personvern-forward ikke-depot-swaps, gebyrbesparende opportunistisk transaksjonsbatching og fremdriftsovervåking av inflight swaps.

Pool er en peer-to-peer-markedsplass for Lightning-kanaler. Den kobler brukere som trenger tilgang til inngående likviditet til de som har kapital å distribuere på Lightning Network ved å gjøre det mulig for en Lightning Network-deltaker å signalisere et behov for det og motivere andre til å åpne kanaler med dem ved å bruke kapitalen deres.

Med LNDs fokus typisk på nye funksjoner og kundestøtte, har CLN-teamet funnet et tomrom i markedet de håper å fylle ved å følge spesifikasjonsprosessen nærmere.

Til spesifikasjon eller ikke til spesifikasjon

"Laboratorieteamet har kommet opp med flotte ting," sa Neigut. "De har bare, som organisasjon, ikke vært fantastiske når det gjelder å skrive spesifikasjoner for tingene de legger til. Et godt eksempel på det er KeySend.»

KeySend lar en Lightning-node sende noen en Lightning-betaling som bare har mottakernodens ID, noe som betyr at verktøyet ikke krever fakturaer, som er gjeldende de facto standard på Lynets betalingsmekanisme.

"De lanserte det, mange begynte å bruke det, men de spesifiserte det aldri helt," la Neigut til. "Så CLN ønsket å kunne støtte det. Et av teammedlemmene våre måtte gå tilbake og finne ut hvordan de skulle få det til å fungere bare ved å lese koden deres og reversere den.»

En spesifikasjon ble til slutt skrevet av Spirals Lightning-implementering, LDK, husket Neigut, etter at teamet omvendt utviklet Lightning Labs-koden.

"Og de andre lagene måtte bare følge med fordi LND har en så stor installasjonsbase," sa hun. "Det er ikke som den mest samarbeidende prosessen."

"Teamet med folk som jobber med Lightning Labs' ting er ganske solid," la Neigut til. "Jeg tror bare de utnytter nettverksdominansen deres til å slippe å gjøre alt dette ekstraarbeidet, for hvis de ikke gjør det, vil noen andre gjøre det fordi flertallet av nodene på nettverket kjører koden deres."

Neigut sa at hun allerede er vant til at LND er i søkelyset og er "standard Lightning"-implementeringen - noe hun innrømmer at hun liker som utvikler på grunn av færre kundestøttekrav hun mottar.

"Men jeg tror at vi ville få en sunnere nettverksdynamikk hvis det ikke var noen majoritetsimplementering," la hun til. "Jeg tror det virkelig ville endre spillet med tanke på hvor mye samarbeid alle må gjøre for å få tingene sine sendt på Lightning. Og det ville være sunt.»

Nøye oppmerksomhet til spesifikasjoner er uten tvil sentralt for utvikling av åpen kildekode i et åpent nettverksmiljø. På Lightning danner slike spesifikasjoner grunnlaget for protokollen og sikrer interoperabiliteten til de forskjellige versjonene som deltar i nettverket.

Men mens noen hevder at store endringer og nye tillegg til en Lightning-implementering bør ha en tilhørende spesifikasjon, kan andre se BOLT-spesifikasjonene som et minimum, på toppen av hvilke hver implementering kan bygge sine egne spennende nye funksjoner – som ikke nødvendigvis trenger å porteres tilbake til spesifikasjonspakken.

"Det er hardt skape et åpen kildekode-infrastrukturselskap, så det er ikke overraskende at jeg ikke er enig i alle [Lightning Labs' prioriteringer», sa Russel. "Jeg tror virkelig de vil finne en måte å både skape en bærekraftig inntektsstrøm og være en pålitelig partner i den tekniske utviklingen av Lightning Network; Jeg tror ingen ønsker å se nettverket delt i biter.»

Å ignorere spesifikasjonsprosessen fullstendig kan føre til fremveksten av vidt forskjellige sub-økosystemer, noe som kan skade utviklingen og adopsjonen av Lightning Network som helhet hvis de skulle bli ikke-interoperable. Men som Russel fremhevet, er det ingen indikasjon på at noen implementering gjør det i dag. Å opprettholde en sammenhengende, interoperabel interaksjon mellom noder er nøkkelen hvis vi ønsker å holde implementeringsdetaljer abstrahert borte fra brukeren og dermed muliggjøre en god brukeropplevelse.

"Hvis [Lightning Labs] var ledende og de også var ledende innen spesifikasjoner, tror jeg at det ville vært litt mindre friksjon rundt å legge til nye funksjoner, fordi det ikke ville være like vanskelig å følge med på hva de gjør, sa Neigut. "Kanskje de vil være mer involvert i spesifikasjonsprosessen fremover. Jeg tror de definitivt har fått tilbakemeldinger fra oss og resten av samfunnet om at spesifikasjonsprosessen er viktig.»

En del av kontroversen og spenninger i BOLT-spesifikasjonsprosessen stamme fra en e-post delt på Twitter i slutten av februar, der sjefen for Lightning-likviditet ved Lightning Labs, Alex Bosworth, kommenterte BOLT 12 og BOLT-spesifikasjonsprosessen.

Bosworth skrev at BOLT-prosessen er en vilkårlig standardiseringsprosess som ikke krever folks samtykke og derfor representerer "mer av et oppfattet sett med dokumenter kontrollert av en vilkårlig prosess enn det er en traktat mellom uavhengige implementeringer."

Lightning Labs senere avklart at Bosworths kommentarer kun reflekterer hans mening og ikke nødvendigvis selskapets.

Core Lightning: Hvordan Blockstreams implementering Rebrand snakker til sin langsiktige visjon for Bitcoin PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.
Bosworth antydet uten tvil å avvise overholdelse av spesifikasjonsprosessen når den er i konflikt med det han kaller "nåværende problemer" i Lightning, ettersom slike standarder kanskje ikke brukes av flertallet av nettverket og derfor ikke burde begrunne mye utviklingsinnsats, mens disse problemene kan representere smertepunkter for flertallet av brukerne og bør derfor prioriteres. Bildekilde.

Decker delte sine tanker om Bosworths kommentarer og om BOLT-spesifikasjonsprosessen under London Bitcoin Devs-møtet.

"Jeg tror det er veldig sterke uttalelser fra noen som aldri har deltatt i et eneste spesifikasjonsmøte," sa han. "Det er litt uenighet i spesifikasjonsprosessen, men det er ved design. Hvis en implementering var i stand til å diktere hvordan hele nettverket ser ut, ville vi ende opp med et veldig nærsynt syn på hva nettverket kunne være, og vi ville ikke være i stand til å betjene alle de forskjellige brukstilfellene vi betjener.»

"Og så ja, noen ganger er spesifikasjonsprosessen frustrerende, jeg er helt enig i det," la han til. «Vi har absolutt ulike syn på hvordan nettverket skal se ut. Men ved denne avhandlingen, antitesen og synteseprosessen kommer vi opp med et system som er mye mer i stand til å tjene våre brukere enn om en implementering skulle gjøre det alene."

"Jeg personlig jobber ikke med spesifikasjonen, så jeg føler meg ikke kvalifisert til å gi et svar," sa Gugger på møtet, og kommenterte Bosworths e-post. «Jeg ville bare legge til at jeg ikke nødvendigvis er enig i alle punktene som Alex nevnte. Jeg ville definitivt sagt det på en annen måte også. Jeg tror mangel på ressurser til å jobbe med spesifikasjonen noen ganger tolkes som at vi blokkerer ting som ikke er intensjonen og ikke vårt mål selvfølgelig. Vi ønsker å legge ned mer arbeid med spesifikasjonen, så jeg håper vi vil forbedre oss der. Det er en interessant ting å observere hvordan den frustrasjonen noen ganger kommer til overflaten. Takk [Decker og ACINQ-utvikler Bastien Teinturier] for alt arbeidet du gjør med spesifikasjonen. Jeg må også hente så jeg skal gjøre mitt beste.»

Russel kommenterte også Bosworths e-post i en Twitter-tråden der han lovet å bruke mer tid på polering og markedsføring av CLN, da han sa at LND ikke implementerte Lightning først og ikke implementerte det best – selv om fellesskapet er flott, la han til.

"Det viser seg at de har bestemt seg for at de kan utnytte nettverksdominans til protokollkontroll, og spesifikasjonsprosessen er ikke 'ekte'," skrev han i tråden. "Lightning Labs har hevdet eierskap til Lightning-nettverket på mange måter: Jeg har vært motvillig til å kalle dem ut offentlig. Men lynnettverket og fellesskapet fortjener bedre.»

Russel svarte ikke på spørsmål fra Bitcoin Magazine henviser til denne tråden. Lightning Labs nektet å kommentere.

"Tilbake i 2016 kom vi fra tre forskjellige retninger og bestemte oss for å slå sammen alle tingene vi lærte under denne innledende eksperimenteringsfasen i en enkelt spesifikasjon slik at vi kunne samarbeide og samarbeide," sa Decker på møtet. «Denne eksperimentelle fasen må alltid følges opp av et forslag som er introspekterbart av alle andre og kan implementeres av alle andre. Noen ganger mangler det formelle forslaget, og det forhindrer at andre implementeringer gir sin egen vurdering av den funksjonen. Denne anmeldelsen er veldig viktig for å sikre at den fungerer for alle og at den er den beste vi kan gjøre den.»

"Som navnet Lightning Network antyder, tjener det veldig mye på nettverkseffektene vi får ved å være kompatible, ved å kunne fungere sammen og gjøre det mulig for alle implementeringer å spille på like vilkår," la han senere til.

Implementeringer utfyller hverandre, de konkurrerer ikke

Foruten den veldig spesifikke kontroversen angående spesifikasjonsprosessen, fungerer Lightning-implementeringer stort sett separat og deretter sammen for å bringe de beste og mest etterspurte funksjonene til nettverket, og sikre en generelt bedre brukeropplevelse.

Som et resultat kommer Blockstreams trekk for å presse CLN som et spesifikasjonskompatibelt, modulært og lett tilbud som et alternativ for de som er interessert i å kjøre en nodeimplementering som streber etter å være fullstendig interoperabel med resten av nettverket og gir en unikt sett med fordeler til de som gjør det.

Ettersom forskjellige implementeringer streber etter å bli deres beste versjon og imøtekomme en spesifikk brukssituasjon ved å utforske sine egne verdiforslag, er det til syvende og sist brukeren som vil dra nytte av ettersom flere og bedre alternativer dukker opp.

Tidstempel:

Mer fra Bitcoin Magazine