Lightning Network tar som bekant bort en del av belastningen från blockkedjan genom att använda betalningskanaler och endast publicera de transaktioner som öppnar respektive stänger kanaler. Däremellan kan ett obegränsat antal transaktioner ske utan att blockkedjan överhuvudtaget rörs genom att användarna löpande uppdaterar en transaktion mellan sig utan att publicera den.
Låt oss först kolla på hur detta går till, hur man kan bibehålla säkerheten utan att faktiskt publicera transaktionen. Vi tittar nu på en enkel betalningskanal mellan Alice och Bob, Lightning Network är ett nätverk av sådana kanaler, vilket du kan läsa mer om här.
Tänk dig en betalningskanal som en kulram. När kanalen öppnas befinner sig alla kulor, låt oss säga 20 stycken, på ena sidan, t.ex. hos Alice. Vill Alice betala 12 kulor till Bob så flyttas 12 kulor från Alices sida till Bobs. Vill Bob sedan betala 5 kulor till Alice så flyttar han 5 kulor och har då 7 kulor kvar på sin sida. Nettoeffekten av alla transaktioner kan beskrivas med en enda transaktion, i det här fallet en transaktion från Alice till Bob på 7 kulor.
Det är den här senaste versionen av transaktionen som beskriver det aktuella förhållandet mellan Alice och Bob och som när som helst skulle kunna publiceras på blockkedjan. Notera dock att det även finns en tidigare opublicerad transaktion som Alice och Bob skapade där Alice betalar 12 kulor till Bob. Den här tidigare transaktionen är ju fördelaktig för Bob så om han vill lura Alice skulle han förstås vilja se till att den transaktion publiceras istället för den senaste. Det som hindrar honom från att göra detta är en finurlig utformning av transaktionen som gör att han om han publicerar den måste vänta 2016 block, eller ca 2 veckor, innan transaktionen går igenom. Under denna tid har Alice (om det finns en senare version av transaktionen) möjlighet att avbryta Bobs transaktion genom att själv publicera en transaktion där alla pengar går till henne.
Det här kan låta lite magiskt och är en aningen förenklad beskrivning så om man verkligen vill förstå exakt hur dessa transaktioner är utformade rekommenderas Bitcoin Magazines artikel Understanding the Lightning Network, Part 1. Det viktiga att ha med sig från detta när vi nu ska prata watchtowers är i alla fall att det finns en transaktion som Alice kan använda för att “straffa” Bob om Bob försöker fuska.
Problemet för Alice i exemplet ovan är hon måste se till att vara online minst en gång varannan vecka för att inte riskera att bli lurad på sina pengar. Bitcoin som förvaras i en vanlig plånbok kan ligga där säkert och tryggt hur länge som helst utan du riskerar något medan bitcoin på Lightningnätverket måste tittas till då och då. Ett s.k. watchtower, eller vakttorn, är en tjänst som ska kunna sköta det här jobbet åt dig genom hålla koll på om Bob publicerar en gammal transaktion och i så fall publicera bestraffningstransaktionen.
.jpg)
Det fina är att du kan anlita ett vakttorn utan att för den sakens skull behöva lämna ut någon känslig information om dina transaktioner. Varje gång en betalningskanal uppdateras skickar Alice en krypterad bit data till vakttornet. Den här datan innehåller det vakttornet behöver för att kunna skicka ut bestraffningstransaktion men informationen är som sagt krypterad och vakttornet har i det här skedet inte tillgång till hela dekrypteringsnyckeln. Dekrypteringsnyckeln består nämligen av transaktions-ID:t för kanalens tidigare tillstånd och i samband med att vakttornet får den krypterade datan får denne också halva detta ID. Om Bob skickar ut den tidigare transaktionen kan vakttornet upptäcka detta genom dennes halva matchar det ID som Bobs transaktion har och eftersom vakttornet nu dessutom har fått tillgång till hela ID:t kan vakttornet dekryptera informationen och utföra bestraffningen.
Om inga oegentligheter sker och Bob aldrig försöker luras har alltså vakttornet endast tillgång till en massa krypterad data så i praktiken ingen väsentlig information alls. Den första implementationen av vakttorn som Lightning Labs nyligen släppte innehåller dels ett “altruistiskt” vakttorn som utför tjänsten helt utan betalning men även ett “basic reward”-vakttorn som ger vakttornet en slant i det läge då det behöver agera och skicka ut bestraffningstransaktionen. Mer sofistikerade lösningar för att ersätta vakttornet för sitt jobb är också under utveckling.
I nuläget behöver man själv leta upp ett (eller flera) vakttorn som man vill anlita men det finns planer på att automatisera även den processen. Notera att du om du är osäker på om ett vakttorn faktiskt kommer att utföra sin uppgift kan anlita flera av varandra oberoende vakttorn och därmed minska risken att jobbet inte blir gjort.
Grotta ner dig i de tekniska detaljerna på GitHub eller läs mer hos Bitcoin Magazine.