Å prøve å navigere i de forskjellige lynimplementeringene kan være en utfordring. Selv om det i utgangspunktet var tre implementeringer: c-lyn, eclair og lnd, fortsetter flere å komme ut av treverket hele tiden med rype, rust-lyn og Electrum, den siste som gikk inn i krig.
Ofte ser det ut til at utviklere og ambisiøse utviklere velger å bruke eller bidra til en bestemt implementering basert på språket det er skrevet på. Kjenner du til Scala? Velg eclair. Opphisset av potensialet til Rust? Velg rust-lyn. Imidlertid er det andre viktige betraktninger som mål, designfilosofier, brukssaker og kompromisser for de forskjellige implementeringene. I tillegg, bare fordi en implementering er skrevet på et bestemt språk, betyr det ikke nødvendigvis at du må kode på det språket for å bidra til økosystemet rundt den implementeringen..
De nye kontrastene mellom de første og rust-lyn implementeringene ble utforsket på et panel på Breaking Bitcoin 2019 og i denne Bitcoin Magazine artikkelen. Mens lnd søker å ta belastningen av utviklerne og tilby den ultimate funksjonaliteten ut av esken, søker rust-lyn å tilby den ultimate fleksibiliteten med utviklere som oppfordres til å ta med sine egne komponenter og plassere dem.
Derimot tilbyr c-lyn en tredje vei. Den har en robust og sikker kjerne som er designet for ikke å bli justert eller erstattet av utvikleren. Fleksibilitet og tilleggsfunksjonalitet er tilgjengelig ved bruk av plugins som kan skrives av utvikleren på forskjellige språk som Python eller Go. Målet er at c-lyn økosystemet skal dukke opp som en testbed for å eksperimentere med nye banebrytende funksjoner, tidligere terrenget til andre implementeringer som lnd og eclair, uten å ofre ytelsen og robustheten til kjernen.
Plugins er underprosesser som startes av main lightningd-demonen. De jobber i samarbeid med lyn. Eventuelle plugins som er overskudd til kravene trenger ikke kjøres. Noen plugins trenger visse kroker for å bli introdusert i lightningd som vil varsle plugins om interne hendelser og / eller endre oppførselen til lightningd.
De første C-Lightning-pluginene
Blockstream har en serie av mellomstore blogginnlegg for å vise frem noen av de første plugins som er skrevet av c-lightning-teamet. Disse inkluderer “Sammendrag” -tillegget som gir et sammendrag av nodestatus inkludert satoshis onchain, hva det utgjør i fiat-termer, antall jevnaldrende, antall kanaler, hvor balansert de er osv..
Pluggen “Probe” bestemmer om det er en rute for å foreta en betaling til en bestemt node i nettverket, returnerer gebyrnivået som kreves og indikerer hvilken (n) kanal (er) som forhindrer en vellykket betaling. Dette kan brukes til å forberede grunnlaget for en fremtidig betaling eller bare for å utforske nettverkets topologi.
“Prometheus” -programmet samler inn data om ytelsen til noden din for å gi visualiseringer og varsler. Med alle disse pluginene kan du velge å bidra til pluginet ved å legge til en funksjon eller bygge din egen fra bunnen av.
Community Plugins
Totalt er det 16 “community curated” plugins for c-lightning tilgjengelig i skrivende stund. Disse inkluderer en plugin for autopilot portet fra et bibliotek bygget av Rene Pickhardt. Autopiloter bestemmer hvilke noder du vil åpne kanaler med på vegne av brukeren. Brukeren må fortelle autopiloten prosentandelen av midler under deres kontroll, antall kanaler som skal åpnes og minimum kanalstørrelse. Autopiloten må også varsles av lynd når kanaler åpnes og lukkes av eksterne parter. Å bygge en effektiv autopilot er utfordrende da brukerpreferanser, som å maksimere sannsynligheten for en vellykket betaling, kan komme i konflikt med nettverkshelsen, for eksempel nivået av desentralisering..
Det er også en ombalansere plugin, som flytter likviditet mellom brukerens kanaler for å sikre at det er tilstrekkelig inn- og utgående likviditet; og en fakturafri betalingsplugg, som lar brukeren foreta en betaling uten å motta en faktura. Når du kjører c-lyn, kan du velge å slå på eller av en kombinasjon av disse pluginene.
Som Lisa Neigut (@niftyneisa i henne tweetstorm, c-lightning gir ikke “et standardisert HTTP-tilgjengelig grensesnitt ut av boksen eller et autentiseringsskjema” for tredjeparts apputviklere som lnd gjør. Men samfunnsbygde plugins gir muligheten til å bygge ekvivalenter for c-lyn som finnes i andre implementeringer.
Kristaps Kaupe har startet en GitHub repo for plugins som etterligner noen første kommandoer. Andre pluginforfattere som er verdt å fremheve er Richard Bondi, som har skrevet en samling plugins i Go, inkludert et plugin for å forby jevnaldrende; fiatjaf, som har skrevet et plugin som implementerer LN URL for å hjelpe betaleren med å kommunisere med betalingsmottaker; og Conor Scott, som har skrevet en rekke plugins i Python inkludert et plugin for å lage kanaler med topp kapasitetsnoder. Endelig, Justin Moon har bygget et proof-of-concept-plugin for å finansiere lynkanaler med hardware-lommebøker.
Utfordringene med plugins
Selv om denne plugin-arkitekturen ser ut til å tilby det beste fra begge verdener, gir den noen utfordringer og potensielle ulemper. Det er ikke klart på dette stadiet om rustens lette fleksibilitet vil bety at den er bedre egnet for eksisterende Bitcoin-lommebøker som ønsker å integrere lyn i deres eksisterende kodebase..
I tillegg, ettersom antall fellesskapsprogrammer multipliserer og verdien av Bitcoin som stoler på disse pluginene øker, vil sikkerhet og kurering være kritisk. Det vil uunngåelig være duplisering og overlapping mellom plugins.
Curation er utfordrende fordi det effektivt anbefaler (uoffisielt, advarselstom) hvilke plugins som skal brukes og hvilke som ikke bør. Uten kurering blir det umulig for brukere og utviklere å komme raskt i gang uten å undersøke alle konkurrerende plugins. Det er et argument for at noen språk (og noen utviklere!) Er bedre egnet til å skrive sikkerhetskritisk programvare. Imidlertid kan de spesielt farlige JSON-RPC-metodene bare installeres med utvikleralternativet, og er bare ment for testing og feilsøking med hjelp fra c-lightning-teamet. Det er også veiledning om farene en plugin-utvikler kan pådra seg når man benytter seg av en bestemt krok som kan endre standardoppførselen til c-lyn..
Det er ikke slik at denne tilnærmingen skaper et perfekt tillatelsesløst miljø for utviklere, da noen fremtidige plugins fortsatt vil kreve at flere kroker blir slått sammen til c-lyn-kodebasen av c-lyn-teamet. For eksempel er en krok for å legge til rette for et vakttårn-plugin diskusjon i skrivende stund. Det er mulig at noen kroker ikke blir slått sammen på grunn av sikkerhetsproblemer eller implementeringsdetaljer.
Det gjenstår å se om forekomster av c-lynnoder som kjører forskjellige sett med plugins, forårsaker kompatibilitetsproblemer mellom c-lynnoder eller med andre implementeringer. Det er allerede utfordrende å sikre kompatibilitet mellom forskjellige implementeringer, forutsatt at c-lyn-noder alle kjører den samme utgivelsen. Eksperimentering er viktig, skjønt, og leksjoner fra denne eksperimenteringen vil være uvurderlig når du fullfører BOLT-spesifikasjonene for Lightning-protokollen.
London Bitcoin Devs
Muligheten til å bygge og leke med nye plugins på et bredt utvalg av forskjellige språk, trekker utviklere til å bygge på toppen av c-lyn. Antoine Poinsot (@darosior) kom til London for å presentere på London Bitcoin Devs møte i mars 2020. Poinsot utvikler en plugin manager kalt Reckless som vil tilby et utvalg plugins til brukeren og starte de valgte plugins dynamisk. Han har også bygget en RPC-kommandokrok som gjør at et plugin kan ta over enhver RPC-kommando og endre den. Dette er potensielt hensynsløst og eksperimentelt ettersom RPC-kommandoer er hvordan brukere samhandler med lyn. Hvis RPC-kommandoer kan aksepteres, avvises eller endres, åpnes det for et antall brukstilfeller men også muligheter for brukere å miste pengene sine.
Denne RPC-kommandokroken dannet grunnlaget for Rusty Russells siste presentasjon på nettet Boltathon 2. Det er fortsatt en hel del plugins som kan bygges fra trampolin ruting til HODL fakturaer, og Christian Decker forventer “Det er allerede et plugin som gjør det” for å bli et meme. I så fall kan Decker og c-lyn-samfunnet bare få arbeidet sitt til å kurere denne nye jungelen av plugins..
Takk til Antoine Poinsot og Christian Decker for deres bidrag til denne artikkelen.