Dit is een hoofdartikel van Shinobi, een autodidactische opvoeder in de Bitcoin-ruimte en technisch georiënteerde Bitcoin-podcasthost.
Kanaalstoring is een van de meest bedreigende openstaande problemen met het Lightning Network. Het biedt een open mechanisme voor denial-of-service-aanvalsknooppunten op het netwerk om te voorkomen dat ze routeren, waardoor ze geld verliezen terwijl hun liquiditeit opgesloten zit en niet in staat is om betalingen door te sturen waarmee ze vergoedingen kunnen verdienen. Een aanvaller kan een betaling via andere knooppunten van zichzelf naar zichzelf leiden en weigeren de betaling af te ronden. Dit maakt die liquiditeit onbruikbaar voor het doorsturen van andere betalingen totdat het gehashte tijdslotcontract (HTLC) tijdslot verloopt en de betalingsrestituties plaatsvinden.
Vorige maand stelde Lightning-ontwikkelaar Antoine Riard een formele specificatie voor voor een oplossing voor dit probleem. In augustus publiceerden Riard en Gleb Naumenko onderzoek naar het algemene probleem zelf, evenals een aantal verschillende oplossingen die kunnen worden gebruikt om het te verminderen of op te lossen. Een van die voorgestelde oplossingen was een vorm van geanonimiseerde referenties die knooppunten konden gebruiken om een soort reputatiescoresysteem te bouwen voor gebruikers die betalingen via hen routeren zonder die reputatie te hoeven doxen of te associëren met een statische identificatie die een negatieve invloed zou hebben op de privacy van mensen. Deze oplossing is nu het formele protocolvoorstel geworden gemaakt door Riard vorige maand.
Inside The Channel Jamming Mitigation Proposal
De kern van het idee is een Chaumian ecash token. Dit zijn gecentraliseerde tokens die zijn uitgegeven door een muntautoriteit op een manier die voorkomt dat de uitgifte van een token wordt gecorreleerd met de inwisseling van een token later. Dit wordt gedaan door een token op een geblindeerde manier te ondertekenen, waardoor de ontvanger van het token het kan deblinderen zonder de handtekening ongeldig te maken. De uitgever kan dan verifiëren dat het een legitiem token is zonder dat token te kunnen koppelen aan het moment waarop het werd uitgegeven.
Het voorstel stelt voor om deze Chaumian-tokens, uitgegeven door elk routeringsknooppunt op het netwerk, te gebruiken als een vorm van reputatiebewijs. Bij het routeren van een betaling zou een Chaumian ecash-token uitgegeven door elk knooppunt in de betalingshop worden verpakt in de uienbundel voor dat knooppunt langs de betaling. Token-eenheden vertegenwoordigen zowel de waarde van de toegestane HTLC als de tijdslotperiode voor terugbetaling. Voordat de HTLC wordt doorgestuurd, controleert elk knooppunt of het token in hun uienblob geldig is en nog nooit eerder is ingewisseld, waarbij de HTLC alleen wordt doorgestuurd als aan beide voorwaarden wordt voldaan.
Als de HTLC met succes wordt afgewikkeld met de onthulling van de preimage, tekent elk knooppunt langs het betalingspad en bevat een nieuw uitgegeven Chaumian-token om samen met de HTLC-preimage terug te sturen naar de afzender. Als de HTLC niet met succes wordt afgehandeld,”verbranden”de routeringsknooppunten het token door het op te nemen in hun verbruikte tokentabel en geven ze geen nieuw token uit. Dit dwingt de afzender om nieuwe tokens van die knooppunten te verwerven om betalingen er weer doorheen te leiden. Het hele concept is dat jamming-aanvallen altijd niet worden opgelost, dus in dit schema worden deze tokens die worden uitgegeven door elk knooppunt waar je doorheen gaat, verbrand als je een jamming-aanval uitvoert en de kosten creëren om meer te verwerven om het opnieuw te doen. Op dit moment kosten jamming-aanvallen niets anders dan tijd, dus dit zou voor hen economische kosten met zich meebrengen.
Dus, het is tijd om de olifant in de kamer te bespreken: hoe start je de uitgifte en verspreiding van deze tokens over het netwerk? Voor elk knooppunt dat u wilt routeren, is een door hen uitgegeven token vereist. De oplossing: ervoor betalen. Een andere voorgestelde oplossing voor het probleem met kanaalstoringen zijn voorafbetalingen, d.w.z. een vergoeding in rekening brengen om zelfs maar te proberen een betaling te routeren, ongeacht of deze al dan niet slaagt. Dus zelfs mislukte betalingen zouden kosten met zich meebrengen voor de afzender.
Het voorstel van Riard is om deze tokens rechtstreeks van elk knooppunt te kopen als eenmalige aankopen. Vanaf dat moment krijgt u, in plaats van vooruitbetalingen te betalen voor elke betaling, zolang de eerdere betaling succesvol is afgehandeld, opnieuw”routeringstokens”uitgegeven waarmee uw volgende voorgestelde betaling zonder kosten kan worden gerouteerd. Op deze manier betalen succesvolle betalingen alleen de daadwerkelijke routeringsvergoeding en betalen mislukte betalingen alleen de vooruitbetaling, waardoor een soort”dubbele vergoeding”voor succesvolle betalingen wordt voorkomen. Beschouw het in ieder geval economisch als een soort tussenweg tussen de huidige stand van zaken, waarbij mislukte betalingen niets kosten en alleen succesvolle betalingen een vergoeding betalen, en een volledig vooruitbetalingsmodel waarbij voor alle betalingen een vooruitbetaling wordt betaald en succesvolle betalen ook een routeringsvergoeding.
Takeaways van het voorstel
Persoonlijk denk ik dat dit soort directe betaling voor tokens vooraf een grote mate van UX-frictie zou kunnen veroorzaken in het proces van het gebruik van het Lightning Network. Ik denk echter dat er een vrij eenvoudige oplossing is voor die wrijving door het voorstel een beetje aan te passen.
In plaats van elk knooppunt specifiek vooraf voor Chaumian-tokens te moeten betalen, zou het voorstel directer kunnen worden gehybridiseerd met het voorstel voor voorafbetalingen. Als je tokens hebt voor een node, neem die dan op in de uienblob, als je niet gewoon een vooruitbetaling betaalt direct binnen het HTLC-voorstel en als de betaling succesvol wordt afgehandeld, krijg je Chaumian tokens terug in verhouding tot wat je hebt gedaan-front vergoeding was. Op deze manier hoeft u in plaats van van tevoren tokens van veel verschillende knooppunten te verzamelen, u ze eenvoudigweg aan tijdens het uitvoeren van de eerste betalingen totdat u een goede verzameling heeft van de verschillende knooppunten die u vaak gebruikt en zeer zelden de kosten hoeft te maken van vooruitbetalingen om ze te bereiken.
Een andere potentiële bron van wrijving is voor node-operators en komt neer op fundamentele problemen van Chaumian ecash zelf. Om ervoor te zorgen dat een token slechts één keer wordt uitgegeven, moet de uitgever een database bijhouden van alle tokens die zijn uitgegeven. Dit groeit voor altijd, waardoor zoekopdrachten om de geldigheid van tokens te controleren steeds duurder en tijdrovender worden naarmate de database groter wordt. Daarom stelt Riard voor om deze Chaumian-tokens periodiek te laten verlopen, op een blokhoogte die wordt geadverteerd in het roddelprotocol per knooppunt. Dit betekent dat afzenders deze tokens periodiek moeten terugkopen, of als de implementatie dit ondersteunt, ze moeten inwisselen voor nieuwe tokens die zijn ondertekend door de nieuwe ondertekeningssleutel nadat de vorige is verlopen.
Dit zou de afzenders van betalingen ofwel regelmatig economische kosten met zich meebrengen, ofwel hen verplichten periodiek in te checken om ervoor te zorgen dat ze opnieuw worden uitgegeven wanneer oude tokens verlopen. In de praktijk kan dit worden geautomatiseerd voor mensen die hun eigen Lightning-knooppunten hebben, en voor elke portemonnee die is gebouwd rond een Lightning-serviceprovider (LSP)-model, zou de LSP zelf de verwerving en het onderhoud van tokens namens zijn gebruikers kunnen afhandelen. tokenvoorziening voor de betalingen van zijn gebruikers. Aan de rand kan dit echter, zonder een volledige Lightning-node of LSP, een beetje vervelend worden voor gebruikers van lichte portemonnees.
Ik denk dat dit voorstel een grote bijdrage kan leveren aan het verminderen van kanaalstoringen als aanvalsvector, vooral als het wat strakker wordt gehybridiseerd met het basistarief vooraf, en de meeste UX-fricties kunnen worden heel gemakkelijk afgehandeld voor LSP-gebruikers en mensen die hun eigen Lightning-nodes bedienen. En zelfs als de voorafbetalingen een hoge mate van wrijving opleveren, is het mogelijk dat het bewijzen van de controle over een Bitcoin UTXO zou kunnen worden gebruikt in plaats van het daadwerkelijk betalen van vergoedingen om tokens te verwerven.
Dit is een gastpost van Shinobi. Geuite meningen zijn volledig van henzelf en komen niet noodzakelijkerwijs overeen met die van BTC Inc of Bitcoin Magazine.
