Core Lightning: hoe Blockstream's implementatie-rebranding spreekt tot zijn langetermijnvisie voor Bitcoin PlatoBlockchain-gegevensintelligentie. Verticaal zoeken. Ai.

Core Lightning: hoe Blockstream's implementatie Rebrand spreekt tot zijn langetermijnvisie voor Bitcoin

De Lightning Network-implementatie van Blockstream, nu Core Lightning genoemd, probeert de interoperabele, op specificatie gerichte standaard van Bitcoin te zijn.

Bitcoin-infrastructuurbedrijf Blockstream heeft onlangs zijn Lightning Network-implementatie omgedoopt van c-lightning naar Core Lightning (CLN) in een poging de langetermijnfocus van het project op interoperabiliteit en specificatiewerk te benadrukken.

De oorspronkelijke naam, die verwees naar de C-programmeertaal waarin de implementatie is ingebouwd, weerspiegelde niet de werkelijke bedoelingen van het bedrijf met het project. Nu probeert Core Lightning de waardepropositie van de Blockstream-implementatie te weerspiegelen.

“We hopen dat de vernieuwde naam de focus van CLN op interoperabiliteit, specificatiewerk en het voortdurende doel om een ​​referentie-implementatie te bieden met prioriteit op correctheid en robuustheid beter communiceert”, aldus het bedrijf in een verklaring. verklaring.

Waarom zijn er verschillende implementaties van het Lightning-netwerk?

Het Lightning Network is een abstract concept van wat in feite veel verschillende Lightning-kanalen met elkaar verbonden zijn. Bliksembetalingskanalen vormen de basis van het netwerk, aangezien twee deelnemers een hoeveelheid bitcoin op de basislaag van het Bitcoin-netwerk opsluiten om onderling snelle en goedkope betalingen buiten de keten uit te voeren. Door echter meer kanalen met verschillende deelnemers te openen, kunnen betalingen vervolgens in dit ‘mesh-netwerk’ worden gerouteerd, van de ene deelnemer naar de andere totdat een eindontvanger van een Lightning-betaling wordt gevonden.

Daarom is de abstractie die is "het Lightning-netwerk” vereist dat verschillende deelnemers met elkaar communiceren, zodat ze elkaars betalingen kunnen routeren en wrijvingsloze interactie mogelijk maken. Deze communicatie vindt plaats tussen knooppunten die de software van het Lightning-protocol draaien en daardoor onder meer betalingen kunnen verzenden en ontvangen.

Terwijl er in Bitcoin momenteel de facto standaard knooppuntsoftware bestaat, Bitcoin Core, is er momenteel meer dan één type Lightning-knooppuntsoftware populair. Als gevolg hiervan is er behoefte aan een set documenten om te dicteren hoe deze verschillende soorten Lightning-knooppunten - ook wel 'implementaties' genoemd - met elkaar kunnen praten.

De Basis van Lightning Technology (BOLT) documenten de set specificaties definiëren waaraan alle implementaties van Lightning-knooppunten moeten voldoen om een ​​stabiele, compliant deelnemer aan het Lightning Network te zijn. Er zijn momenteel 11 BOLT-documenten die alles beschrijven, van het opzetten van een betalingskanaal en het financieren met bitcoin tot hoe men een Lightning-betaling moet aanvragen.

Het feit dat er verschillende Lightning-implementaties zijn, betekent uiteraard ook dat er verschillende aanbiedingen beschikbaar zijn voor gebruikers, en dat ze kunnen kiezen welke software ze willen gebruiken op basis van hun specifieke behoeften. Op hoog niveau zijn er vier grote Lightning-implementaties, LND, Core Lightning, Eclair en LDK, elk gericht op specifieke gebruiksscenario's.

Kernbliksem: opgebouwd vanuit BOLT

CLN, voorheen c-lightning, wordt sinds begin 2018 in productie gebruikt op het Bitcoin-mainnet. Geschreven in de programmeertaal C, die ontwikkelaars zelfs op een laag niveau een hoge mate van controle biedt over het gedrag van hun code, heeft CLN een focus op efficiëntie en op het bieden van modulaire, op plug-ins gebaseerd implementatie van het Layer 2-schaalprotocol van Bitcoin.

“We streven ernaar een krachtige, enterprise-grade, spec-compatibele implementatie te zijn,” vertelde Lightning-ontwikkelaar bij Blockstream, Rusty Russell, Bitcoin Magazine. “Dat betekent traditioneel dat we meer bedoeld zijn voor high-end gebruikers, bedrijven en ontwikkelaars om op te bouwen.”

CLN werkt alleen op Linux en MacOS, en vereist een lokale of externe bitcoind versie 0.16 of hoger die volledig in verbinding staat met het netwerk waarop de gebruiker draait en waarvandaan transacties worden doorgestuurd. Snoeien wel gedeeltelijk ondersteund.

Als lichtgewicht implementatie maakt CLN een groot aanpassingsniveau mogelijk, omdat de gebruiker er zijn eigen versie van kan maken en alleen de functies kan toevoegen die hij of zij wil of nodig heeft. Ontwikkelaars kunnen communiceren met de daemon via aangepaste JSON-RPC-methoden, waardoor ze de functionaliteit efficiënt kunnen aanpassen aan hun behoeften via plug-ins die rechtstreeks toegang hebben tot details op laag niveau.

De modulariteit, efficiëntie en coderobuustheid van CLN brengen ook de bijbehorende nadelen met zich mee. Christian Decker, een onderzoeker bij Blockstream die zich richt op het opschalen van oplossingen voor Bitcoin, zei tijdens de Londense Bitcoin Devs-bijeenkomst vorige maand dat CLN, door vast te houden aan de UNIX-filosofie om één ding heel goed te doen en geen beslissingen aan de gebruiker op te dringen, op een “kale” manier komt en enige toewijding van de gebruiker vereist om het werkend te krijgen .

Opvallend is dat de implementatie van Blockstream sterk gericht is op het specificatieproces en een groot deel van de code rechtstreeks uit de BOLT-specificaties genereert, aldus Russell. Hoewel dit zorgt voor een implementatie die volledig voldoet aan de specificaties, heeft het team minder tijd om zijn werk op de markt te brengen. Dit is de reden dat het minder gemeenschapsbetrokkenheid en minder knooppuntaandeel ziet dan bij andere implementaties.

“We zijn letterlijk gebouwd op basis van de Lightning BOLT-specificaties!” vertelde Russell Bitcoin Magazine. “Dit betekent dat we veel aandacht besteden (en als team enorm veel moeite hebben gedaan) aan het coördineren van de architectuur van het gehele Lightning Network via de BOLT-specificaties.”

Het team stelt gewoonlijk een nieuwe specificatie voor aan de bredere ontwikkelingsgemeenschap voordat deze aan CLN wordt toegevoegd, in een poging om compatibiliteit op lange termijn tussen verschillende implementaties te garanderen en tegelijkertijd meer ogen te vragen om de code te beoordelen, testen en becommentariëren voordat deze uiteindelijk in een nieuwe wordt omgezet. BOLT en wordt klaar om door alle implementaties te worden geadopteerd.

“Een deel van de reden dat we het spec-and-review-over-implementaties-proces doen, is dat het helpt betere manieren te identificeren om dingen te doen – bugs te vinden, toekomstige problemen te identificeren”, vertelt Lisa Neigut, Lightning-protocolingenieur bij Blockstream. Bitcoin Magazine.

Gezien de efficiëntie en het lichte gewicht is CLN waarschijnlijk de meest geschikte implementatie voor apparaten met lage specificaties.

Het team van Blockstream heeft ook een reeks nieuwe functies ontwikkeld die de huidige functionaliteit van BOLT's uitbreiden. Dit zijn vaak conceptspecificaties of specificatievoorstellen, waaronder collaboratieve kanaalopeningen, liquiditeitsadvertenties en BOLT 12. CLN geeft de gebruiker de mogelijkheid om deze aankomende specificaties uit te proberen.

"We zetten conceptdelen van de Lightning-specificatie af onder experimentele opties", vertelde Russell Bitcoin Magazine. “Maar als je avontuurlijker bent, bieden die experimentele opties je een

inzicht in wat er hierna naar het Lightning Network komt!”

Door samenwerkingskanalen te openen, voorheen 'dubbele financieringskanalen' genoemd, kunnen deelnemers gezamenlijk een nieuw kanaal openen het gezamenlijk financieren van de kanaalfinancieringstransactie. Momenteel zijn kanalen open met een eenzijdige financieringstransactie door één deelnemer. Collaboratieve kanaalopeningen maken ook gedistribueerde CoinJoins mogelijk in een open Lightning-kanaal.

“Je kunt je eigen CoinJoin orkestreren met een aantal andere Lightning-nodes,” vertelde Neigut Bitcoin Magazine. "Je doet het gedecentraliseerd, dus de enige mensen die weten wie daarbij betrokken zijn, zijn de mensen die daadwerkelijk deel uitmaken van die transactie, dus er is geen centrale coördinator die ervoor zorgt dat het gebeurt."

Liquiditeitsadvertenties maken ook gebruik van samenwerkingskanaalopeningen. Volgens een Blockstream blogpost, “ze zijn een lichtgewicht manier om de mogelijkheid te bieden om de liquiditeitsinzet binnen het netwerk op een gedecentraliseerde en toegankelijke manier te coördineren.”

De functie probeert een veelvoorkomend probleem in Lightning op te lossen: inkomende liquiditeit.

Met liquiditeitsadvertenties kunt u “alle mensen zien die adverteren dat ze u inkomende liquiditeit zullen verkopen als u een kanaal voor hen opent, wat echt opwindende dingen zijn”, zei Neigut.

BOLT 12 is een andere conceptspecificatie voor Lightning-portefeuilles en knooppunten met experimentele ondersteuning in CLN. De voorgestelde functie, genaamd ‘aanbiedingen’, zou BOLT 11-facturen verbeteren door herbruikbare aanbiedingen mogelijk te maken, terwijl een BOLT 11-factuur slechts één keer kan worden gebruikt. Hoewel een factuur uitsluitend een betaalverzoek is, kunt u een aanbieding gebruiken om ook geld te verzenden en niet alleen te ontvangen.

CLN-gebruikers kunnen nu ook hun knooppuntbeheertaken automatiseren CLBOSS, een onlangs uitgebrachte tool voor ‘kunstmatige intelligentie’ die kan beslissen voor welke knooppunten kanalen moeten worden geopend, kanalen kan openen wanneer de kosten laag zijn en er fondsen op de keten zijn, routeringskosten kan worden aangepast om concurrerend te zijn met andere knooppunten, onderzeese swaps kan uitvoeren via de Boltz .exchange API en breng kanalen automatisch opnieuw in evenwicht.

Hoewel verschillende implementaties moeten worden aangemoedigd om op zichzelf staande oplossingen te zoeken voor hun specifieke gebruiksscenario's, terwijl ze zich houden aan de huidige BOLT 11-specificaties, is het over het algemeen een goede gewoonte om een ​​begeleidend specificatievoorstel naar voren te brengen om andere implementaties te helpen dezelfde (of een vergelijkbare) functie in te zetten. een stap zou tegemoetkomen aan de langetermijnbelangen van Lightning's brede en steeds groeiende gebruikersbasis. Dat gezegd hebbende, is het specificatieproces geen gemakkelijke taak.

“Het is een lastig proces en het kost veel tijd. Het vereist wel coördinatie met andere mensen met veel verschillende perspectieven”, aldus Neigut.

Als gevolg hiervan besteden verschillende bedrijven verschillende hoeveelheden tijd en moeite aan dit proces, afhankelijk van hun individuele prioriteiten, die uiteraard verschillen. Terwijl het CLN-team volgens Russell het grootste deel van zijn “inspanning heeft besteed aan de specificatie en implementatiedetails op laag niveau en vrijwel geen moeite heeft besteed aan het bereiken van ontwikkelaars of marketing”, heeft Lightning Labs, het bedrijf achter LND, er vaak voor gekozen zich meer te concentreren technische middelen voor nieuwe functies en het oplossen van de pijnpunten van klanten dan voor het moeizame specificatieproces.

LND: hiaten die CLN kan opvullen?

LND is een Lightning-implementatie die op de eerste plaats staat bij de ontwikkelaar en die zich richt op het vergemakkelijken van de ontwikkeling van applicaties daarbovenop, waarbij sterke nadruk wordt gelegd op de interactie van ontwikkelaars, met name in een standaardbenadering van communicatie via REST API's, die eenvoudigere app-ontwikkeling mogelijk maken, naast het bieden van duidelijke documentatie en een eenvoudige installatie-ervaring.

“We willen dat ontwikkelaars het gemakkelijk kunnen oppikken, in hun product kunnen integreren, er apps bovenop kunnen bouwen en het kunnen distribueren als een portemonnee of een zelfgehost knooppunt”, LND-ontwikkelaar Oliver Gugger zei tijdens de Bitcoin Devs-bijeenkomst in Londen. “Breng het naar het plebs.”

Als gevolg hiervan richt LND zich op “het hebben van een geweldige ontwikkelaarsinterface”, voegde Gugger eraan toe, door gRPC en REST in te schakelen.

“LND heeft een geweldige community, eenvoudige installatie en geweldige ontwikkelaarsdocumentatie”, zei Russell toen hem werd gevraagd waarom hij dacht dat LND de populairste Lightning-implementatie is.

LND heeft van alle implementaties de grootste gemeenschapsbetrokkenheid gezien en beheert momenteel het merendeel van alle netwerkknooppunten. Sommige schattingen het aandeel van LND in het totale aantal openbare Lightning-knooppunten ergens tussen de 70% en 90% ligt.

LND beschikt ook over wat misschien wel het grootste fulltime ontwikkelingsteam is. Als gevolg hiervan is het team erin geslaagd een overvloed aan diensten met toegevoegde waarde rond LND op te bouwen, zoals opening en de liquiditeitsdiensten Lightning Ringleiding en Zwembad.

Loop maakt gebruik van submarine swaps om on-chain en off-chain bitcoin te overbruggen, waardoor het gemakkelijk wordt om bitcoin naar en uit het Lightning Network te verplaatsen. Het voert geautomatiseerde kanaalbalancering, privacy-forward niet-custodial swaps, kostenbesparende opportunistische transactiebatches en voortgangsmonitoring van in-flight swaps uit.

Pool is een peer-to-peer-marktplaats voor Lightning-kanalen. Het verbindt gebruikers die toegang nodig hebben tot inkomende liquiditeit met degenen die kapitaal hebben om in te zetten op het Lightning Network, door een Lightning Network-deelnemer in staat te stellen de behoefte daaraan aan te geven en anderen te stimuleren om met hen kanalen te openen met behulp van hun kapitaal.

Omdat de focus van LND doorgaans ligt op nieuwe functies en klantenondersteuning, heeft het CLN-team een ​​gat in de markt gevonden dat het hoopt te vullen door meer aandacht te besteden aan het specificatieproces.

Naar specificatie of niet naar specificatie

“Het Labs-team heeft geweldige dingen bedacht”, zei Neigut. “Ze zijn als organisatie gewoon niet geweldig geweest in het schrijven van specificaties voor de dingen die ze toevoegen. Een mooi voorbeeld daarvan is KeySend.”

SleutelVerzenden staat een Lightning-node toe iemand een Lightning-betaling te sturen met alleen de ID van het ontvangende knooppunt, wat betekent dat de tool geen facturen vereist, die de huidige zijn de facto standaard over het betalingsmechanisme van Lightning.

“Ze lanceerden het, veel mensen begonnen het te gebruiken, maar ze hebben het nooit volledig gespecificeerd,” voegde Neigut eraan toe. “Dus CLN wilde het kunnen ondersteunen. Een van onze teamleden moest het nog eens doornemen en uitzoeken hoe het te laten werken, gewoon door hun code te lezen en er reverse-engineering aan toe te passen.”

Een specificatie werd uiteindelijk geschreven door de Lightning-implementatie van Spiral, LDK, herinnerde Neigut zich, nadat het team de code van Lightning Labs had reverse-engineered.

“En de andere teams hoefden eigenlijk alleen maar mee te doen omdat LND zo’n grote installatiebasis heeft”, zei ze. “Dat is niet het meest collaboratieve proces.”

"Het team van mensen die aan de dingen van Lightning Labs werken, is behoorlijk solide", voegde Neigut eraan toe. "Ik denk gewoon dat ze misbruik maken van hun netwerkdominantie om al dat extra werk niet te hoeven doen, want als zij het niet doen, zal iemand anders het wel doen, omdat de meerderheid van de knooppunten in het netwerk hun code uitvoeren."

Neigut zei dat ze er al aan gewend is dat LND in de schijnwerpers staat en de “standaard Lightning” -implementatie is – iets waarvan ze bekent dat ze er als ontwikkelaar van geniet vanwege de minder verzoeken om klantenondersteuning die ze ontvangt.

“Maar ik denk dat we een gezondere netwerkdynamiek zouden krijgen als er geen meerderheidsimplementatie zou plaatsvinden,” voegde ze eraan toe. “Ik denk dat dit de game echt zou veranderen in termen van de hoeveelheid samenwerking die iedereen moet doen om zijn spullen via Lightning te laten verzenden. En dat zou gezond zijn.”

Zorgvuldige aandacht voor specificaties is misschien wel van cruciaal belang voor open source-ontwikkeling in een open netwerkomgeving. Op Lightning vormen dergelijke specificaties de basis van het protocol en zorgen ze voor de interoperabiliteit van de verschillende versies die aan het netwerk deelnemen.

Hoewel sommigen beweren dat grote veranderingen en nieuwe toevoegingen aan één Lightning-implementatie een begeleidende specificatie zouden moeten hebben, zien anderen de BOLT-specificaties misschien als een absoluut minimum waarbovenop elke implementatie zijn eigen opwindende nieuwe functies kan bouwen – wat niet noodzakelijkerwijs nodig is. worden teruggezet naar de spec suite.

"Haar hard het creëren van een open-source infrastructuurbedrijf, dus het is niet verrassend dat ik het niet eens ben met alle prioriteiten van [Lightning Labs]”, aldus Russell. “Ik geloof oprecht dat ze een manier zullen vinden om zowel een duurzame inkomstenstroom te creëren als een betrouwbare partner te zijn in de technische ontwikkeling van het Lightning Network; Ik denk niet dat iemand het netwerk in stukken wil zien splitsen.”

Het volledig negeren van het spec-proces zou kunnen leiden tot het ontstaan ​​van zeer verschillende sub-ecosystemen, wat de ontwikkeling en adoptie van het Lightning Network als geheel zou kunnen schaden als deze niet-interoperabel zouden worden. Maar zoals Russell benadrukte, zijn er geen aanwijzingen dat enige implementatie dat vandaag de dag doet. Het handhaven van een samenhangende, interoperabele interactie tussen knooppunten is van cruciaal belang als we implementatiedetails buiten het bereik van de gebruiker willen houden en daardoor een goede gebruikerservaring mogelijk willen maken.

“Als [Lightning Labs] de leiding zou hebben en zij zouden ook voorop lopen op het gebied van specificaties, denk ik dat er iets minder wrijving zou zijn rond het toevoegen van nieuwe functies, omdat het niet zo moeilijk zou zijn om te volgen wat ze doen. ' zei Neigut. “Misschien zullen ze in de toekomst meer betrokken worden bij het specificatieproces. Ik denk dat ze zeker feedback van ons en de rest van de gemeenschap hebben gekregen dat het specificatieproces belangrijk is.

Een deel van de controverse en spanningen in het BOLT-specificatieproces voortkomen uit een e-mail gedeeld op Twitter eind februari, waarin Alex Bosworth, hoofd van Lightning-liquiditeit bij Lightning Labs, commentaar gaf op BOLT 12 en het BOLT-specificatieproces.

Bosworth schreef dat het BOLT-proces een willekeurig standaardisatieproces is dat geen toestemming van mensen vereist en daarom “meer een eigenzinnige reeks documenten vertegenwoordigt die worden gecontroleerd door een willekeurig proces dan dat het een verdrag tussen onafhankelijke implementaties is.”

Lightning Labs later verduidelijkt dat de opmerkingen van Bosworth alleen zijn mening weerspiegelen en niet noodzakelijkerwijs die van het bedrijf.

Core Lightning: hoe Blockstream's implementatie-rebranding spreekt tot zijn langetermijnvisie voor Bitcoin PlatoBlockchain-gegevensintelligentie. Verticaal zoeken. Ai.
Bosworth heeft aantoonbaar gezinspeeld op het afwijzen van de naleving van het specificatieproces wanneer dit in strijd is met wat hij ‘huidige problemen’ in Lightning noemt, omdat dergelijke standaarden mogelijk niet door de meerderheid van het netwerk worden gebruikt en daarom niet veel ontwikkelingsinspanningen zouden moeten rechtvaardigen, terwijl deze problemen zou voor de meerderheid van de gebruikers pijnpunten kunnen zijn en zou daarom prioriteit moeten krijgen. Beeldbron.

Decker deelde zijn mening over de opmerkingen van Bosworth en over het BOLT-specificatieproces tijdens de London Bitcoin Devs-bijeenkomst.

“Ik denk dat dit zeer krachtige uitspraken zijn van iemand die nog nooit aan een enkele specificatiebijeenkomst heeft deelgenomen”, zei hij. “Er is wat discussie in het specificatieproces, maar dat is inherent aan het ontwerp. Als één implementatie zou kunnen dicteren hoe het hele netwerk eruit ziet, zouden we eindigen met een zeer kortzichtig beeld van wat het netwerk zou kunnen zijn en zouden we niet alle verschillende gebruiksscenario’s kunnen bedienen die we bedienen.”

“En ja, soms is het specificatieproces frustrerend, daar ben ik het volledig mee eens”, voegde hij eraan toe. “We hebben zeker verschillende opvattingen over hoe het netwerk eruit zou moeten zien. Maar door dit thesis-, antithese- en syntheseproces komen we tot een systeem dat onze gebruikers veel beter van dienst kan zijn dan wanneer één implementatie het alleen zou doen.”

"Persoonlijk werk ik niet aan de specificaties, dus ik voel me niet gekwalificeerd om een ​​antwoord te geven", zei Gugger tijdens de bijeenkomst, in commentaar op de e-mail van Bosworth. “Ik wilde er alleen aan toevoegen dat ik het niet noodzakelijkerwijs eens ben met alle punten die Alex noemde. Ik zou het zeker ook op een andere manier hebben gezegd. Ik denk dat een gebrek aan middelen om aan de specificatie te werken soms wordt geïnterpreteerd als het blokkeren van dingen die niet de bedoeling zijn en natuurlijk niet ons doel. We willen meer werk aan de specificaties doen, dus ik hoop dat we daar verbeteringen zullen aanbrengen. Het is interessant om te zien hoe die frustratie soms aan de oppervlakte komt. Bedankt [Decker en ACINQ-ontwikkelaar Bastien Teinturier] voor al het werk dat jullie aan de specificatie doen. Ik moet ook oppakken, dus ik zal mijn best doen.

Russell gaf ook commentaar op de e-mail van Bosworth in een Twitter thread waar hij beloofde meer tijd te besteden aan het polijsten en op de markt brengen van CLN, omdat hij zei dat LND Lightning niet als eerste en ook niet als beste heeft geïmplementeerd – hoewel de gemeenschap geweldig is, voegde hij eraan toe.

"Het blijkt dat ze besloten hebben dat ze netwerkdominantie kunnen gebruiken voor protocolcontrole, en dat het specificatieproces niet 'echt' is", schreef hij in de thread. “Lightning Labs heeft op veel manieren het eigendom van het Lightning-netwerk opgeëist: ik ben terughoudend geweest om ze in het openbaar aan te spreken. Maar het bliksemnetwerk en de community verdienen beter.”

Russell reageerde niet op vragen van Bitcoin Magazine verwijzend naar dit draadje. Lightning Labs weigerde commentaar te geven.

“In 2016 kwamen we uit drie verschillende richtingen en besloten om alle dingen die we tijdens deze eerste experimenteerfase hadden geleerd samen te voegen in één enkele specificatie, zodat we konden samenwerken en samenwerken”, zei Decker tijdens de bijeenkomst. “Deze experimentele fase moet altijd worden gevolgd door een voorstel dat voor iedereen introspecteerbaar is en door iedereen kan worden geïmplementeerd. Soms ontbreekt dat formele voorstel en dat verhindert dat de andere implementaties hun eigen beoordeling over die functie geven. Deze beoordeling is erg belangrijk om ervoor te zorgen dat deze voor iedereen werkt en dat we er het beste van kunnen maken.”

“Zoals de naam Lightning Network suggereert, profiteert het enorm van de netwerkeffecten die we krijgen door compatibel te zijn, door met elkaar te kunnen samenwerken en ervoor te zorgen dat alle implementaties op een gelijk speelveld kunnen spelen”, voegde hij er later aan toe.

Implementaties vullen elkaar aan, ze concurreren niet

Naast deze zeer specifieke controverse over het specificatieproces, werken Lightning-implementaties meestal afzonderlijk en vervolgens samen om de beste en meest gevraagde functies naar het netwerk te brengen, waardoor een algehele betere gebruikerservaring wordt gegarandeerd.

Als gevolg hiervan komt de stap van Blockstream om CLN te pushen als een spec-compliant, modulair en lichtgewicht aanbod als een alternatief voor diegenen die geïnteresseerd zijn in het uitvoeren van een knooppuntimplementatie die ernaar streeft volledig interoperabel te zijn met de rest van het netwerk en een unieke reeks voordelen voor degenen die dat wel doen.

Terwijl verschillende implementaties ernaar streven hun beste versie te worden en tegemoet te komen aan een specifiek gebruiksscenario door hun eigen waardepropositie te verkennen, is de gebruiker uiteindelijk degene die hiervan profiteert naarmate er steeds betere opties ontstaan.

Tijdstempel:

Meer van Bitcoin Magazine