Att försöka navigera i olika Lightning-implementationer kan vara en utmaning. Även om det ursprungligen fanns tre implementeringar: c-blixt, eclair och lnd, fortsätter fler att komma ut ur träarbetet hela tiden med ripa, rost-blixt och Electrum det senaste för att komma in i striden.
Ofta verkar det som utvecklare och blivande utvecklare väljer att använda eller bidra till en viss implementering baserat på språket det är skrivet på. Känner du till Scala? Välj eclair. Upphetsad av Rust potential? Välj rost-blixt. Det finns dock andra viktiga överväganden som mål, designfilosofier, användningsfall och kompromisser för de olika implementeringarna. Dessutom, bara för att en implementering är skriven på ett visst språk betyder inte nödvändigtvis att du är skyldig att koda på det språket för att bidra till ekosystemet runt det implementeringen.
De framväxande kontrasterna mellan lnd- och rostblixtimplementeringarna undersöktes på en panel på Breaking Bitcoin 2019 och i denna Bitcoin Magazine-artikel. Medan lnd försöker ta bort belastningen från utvecklare och ge ultimat funktionalitet ur lådan, försöker rostbelysning erbjuda ultimat flexibilitet med utvecklare som uppmuntras att ta med sina egna komponenter och sätta i.
Däremot erbjuder c-lightning ett tredje sätt. Den upprätthåller en robust och säker kärna som är utformad för att inte justeras eller ersättas av utvecklaren. Flexibilitet och ytterligare funktionalitet är tillgänglig genom användning av plugins som kan skrivas av utvecklaren på olika språk som Python eller Go. Målet är att c-lightning-ekosystemet ska framstå som en testbädd för att experimentera med nya banbrytande funktioner, tidigare terrängen för andra implementeringar som lnd och eclair, utan att offra kärnans prestanda och robusthet.
Plugins är underprocesser som startas av huvudblixtdemon. De arbetar i samarbete med lightningd. Eventuella plugins som överskrider kraven behöver inte köras. Vissa plugins behöver vissa krokar införas i lightningd som meddelar plugins om interna händelser och / eller förändrar lightningd.
De första C-Lightning Plugins
Blockstream har en serier av medelstora blogginlägg för att visa upp några av de första plugins som skrivits av c-lightning-teamet. Dessa inkluderar plugin “Sammanfattning” som ger en sammanfattning av nodstatus inklusive satoshis onchain, vad det motsvarar i fiat termer, antal kamrater, antal kanaler, hur balanserade de är, etc..
Plugin “Probe” avgör om det finns en rutt för att göra en betalning till en viss nod i nätverket, returnerar den avgiftsnivå som krävs och anger vilken eller vilka kanaler som förhindrar en lyckad betalning. Detta kan användas för att förbereda grunden för en framtida betalning eller bara för att utforska nätverkets topologi.
Plugin “Prometheus” samlar in data om din nods prestanda för att tillhandahålla visualiseringar och varningar. Med alla dessa plugins kan du välja att bidra till plugin genom att lägga till en funktion eller bygga din egen från grunden.
Community-plugins
Totalt finns det 16 ”community curated” plugins för c-lightning tillgängliga i skrivande stund. Dessa inkluderar en plugin för autopilot portas från ett bibliotek byggt av Rene Pickhardt. Autopiloter bestämmer vilka noder som ska öppnas kanaler med för användarens räkning. Användaren måste berätta för autopiloten hur många procent av medlen de kontrollerar, antalet kanaler som ska öppnas och den minsta kanalstorleken. Autopiloten måste också meddelas av lightningd när kanaler öppnas och stängs av fjärrpartier. Att bygga en effektiv autopilot är utmanande eftersom användarinställningar, som att maximera sannolikheten för en framgångsrik betalning, kan komma i konflikt med nätverkshälsan, till exempel nivån av decentralisering.
Det finns även en återbalansera plugin, som flyttar likviditet mellan användarens kanaler för att säkerställa att det finns tillräcklig inkommande och utgående likviditet; och en faktureringsfritt betalningsplugin, vilket gör det möjligt för en användare att göra en betalning utan att först få en faktura. När du kör c-lightning kan du välja att slå på eller av vilken kombination som helst av dessa plugins.
Som Lisa Neigut (@niftyneisa i henne tweetstorm, c-lightning tillhandahåller inte “ett standardiserat HTTP-tillgängligt gränssnitt direkt eller ett autentiseringsschema” för app-utvecklare från tredje part som lnd gör. Men samhällsbyggda plugins erbjuder möjlighet att bygga ekvivalenter för c-lightning som finns i andra implementeringar.
Kristaps Kaupe har startat en GitHub repo för plugins som emulerar några lnd-kommandon. Andra pluginförfattare som är värda att belysa är Richard Bondi, som har skrivit en samling plugins i Go, inklusive ett plugin för att förbjuda kamrater; fiatjaf, som har skrivit ett plugin implementering LN-URL för att hjälpa betalaren interagera med betalningsmottagaren; och Conor Scott, som har skrivit ett antal plugins i Python inklusive ett plugin för att skapa kanaler med toppkapacitetsnoder. Till sist, Justin Moon har byggt ett proof-of-concept-plugin för att finansiera Lightning-kanaler med plånböcker för hårdvara.
Utmaningarna med plugins
Även om den här plugin-arkitekturen verkar erbjuda det bästa från båda världarna, innebär det vissa utmaningar och potentiella nackdelar. Det är inte klart i detta skede om den ultimata flexibiliteten för rostbelysning kommer att innebära att den är bättre lämpad för befintliga Bitcoin-plånböcker som vill integrera Lightning i deras befintliga kodbas.
Dessutom, när antalet community-plugins multipliceras och värdet av Bitcoin som förlitar sig på dessa plugins ökar, kommer säkerhet och kurering att vara avgörande. Det kommer oundvikligen att finnas dubblering och överlappning mellan plugins.
Curation är utmanande eftersom det effektivt rekommenderar (inofficiellt, varningstömning) vilka plugins som ska användas och vilka inte. Utan curation blir det omöjligt för användare och utvecklare att komma igång snabbt utan att undersöka alla konkurrerande plugins. Det finns ett argument att vissa språk (och vissa utvecklare!) Är bättre lämpade för att skriva säkerhetskritisk programvara. De särskilt farliga JSON-RPC-metoderna kan dock bara installeras med utvecklaralternativet och är endast avsedda för testning och felsökning med hjälp av c-lightning-teamet. Det finns också vägledning om de faror som en plugin-utvecklare kan drabbas av när man utnyttjar en viss krok som kan ändra standardbeteendet hos c-lightning.
Det är inte så att detta tillvägagångssätt skapar en perfekt tillståndlös miljö för utvecklare, eftersom vissa framtida plugins fortfarande kräver att ytterligare krokar slås samman i c-lightning-kodbasen av c-lightning-teamet. Till exempel finns en krok för att underlätta ett vakttorn-plugin diskussion i skrivande stund. Det är möjligt att vissa krokar inte slås samman på grund av säkerhetsproblem eller implementeringsdetaljer.
Det återstår att se om förekomster av c-blixtnoder som kör olika uppsättningar plugins orsakar kompatibilitetsproblem mellan c-blixtnoder eller med andra implementeringar. Det är redan utmanande att säkerställa kompatibilitet mellan olika implementeringar, förutsatt att c-blixtnoder alla kör samma version. Experimentering är dock viktigt, och lärdomar från detta experiment kommer att visa sig vara ovärderliga när BOLT-specifikationerna för Lightning-protokollet slutförs.
London Bitcoin Devs
Möjligheten att bygga och leka med nya plugins på ett brett urval av olika språk drar utvecklare till att bygga ovanpå c-lightning. Antoine Poinsot (@darosior) kom till London för att presentera på London Bitcoin Devs möte i mars 2020. Poinsot utvecklar ett plugin manager kallas Reckless som kommer att erbjuda ett urval av plugins till användaren och starta de valda pluginsna dynamiskt. Han har också byggt en RPC-kommandokrok som gör det möjligt för ett plugin att ta över alla RPC-kommandon och ändra det. Detta är potentiellt hänsynslöst och experimentellt eftersom RPC-kommandon är hur användare interagerar med lightningd. Om RPC-kommandon kan accepteras, avvisas eller ändras öppnas ett antal användningsfall men också möjligheter för användare att förlora sina pengar.
Denna RPC-kommandokrok låg till grund för Rusty Russells senaste presentation på nätet Boltathon 2. Det finns fortfarande en hel del plugins som kan byggas från trampolin routing till HODL-fakturor, och Christian Decker förväntar sig “Det finns redan ett plugin som gör det” för att bli ett meme. I så fall kan Decker och c-lightning-communityn bara få sitt arbete att klippa ut för att kurera denna växande djungel av plugins.
Tack till Antoine Poinsot och Christian Decker för deras bidrag till den här artikeln.