Det finns ett behov av att stärka Bitcoin-ekosystemet för människor vars enda datoranordning är en smartphone och som bor där mobil internetaccess är dyr, långsam, opålitlig eller censurerad. Senegalesisk Bitcoin-utvecklare Fodé Diop har påpekat att många delar av världen är “bara mobila”, inte bara “mobila först.”

Mobilplånboksappar som tillåter användare att behålla kontrollen över sina privata nycklar för signering av transaktioner, men inte fungerar som fulla Bitcoin-noder, kallas vanligtvis ”lätta” klienter. Lätta klienter gör avvägningar för integritet och förtroendeminimering för att minska minnet, ihållande lagring och kommunikationsbandbredd de behöver. Den här artikeln fokuserar på hur man minimerar bandbredden som används av lätta klientplånböcker som körs på en mobiltelefon.

Lätta kunder har mycket lägre bandbreddskrav än hela noder eftersom de inte laddar ner hela Bitcoin-blockkedjan. Istället använder lätta kunder någon form av ”enkel betalningsverifiering” (SPV) för att bekräfta transaktioner. I stället för att direkt bekräfta giltigheten för varje transaktion som läggs till Bitcoins huvudbok sedan genblocket, bekräftar en SPV-plånbok bara att de specifika transaktionerna som är associerade med plånboken har lagts till i ett block och att detta block är en del av kedjan av block med de flesta arbetar med att säkra det. En SPV-plånbok antar, men verifierar inte, att majoriteten av ärliga gruvarbetare bara kommer att bidra till att utöka blockchain byggt från transaktioner som följer konsensusreglerna för Bitcoin.

I denna tekniska diskussion undersöker vi de lätta klienternas bandbreddskrav och de subtila säkerhets- och sekretessavvägningar som finns för lätta klienter utformade för att fungera med begränsad internetanslutning.

Lätta kundavvägningar

Den säkraste lösningen för användare är att köra och bekräfta betalningar med sin egen Bitcoin-fullnod. Det finns dock en viss korrelation mellan länder där människor förlitar sig på relativt dyra eller opålitliga uppmätta internetanslutningar – där Bitcoins censurmotstånd behövs mest – och de där det är osannolikt att människor har tekniska eller ekonomiska resurser för att driva en Bitcoin-fullnod. I många delar av världen kommer Bitcoin-användare inte att ha något annat alternativ än att använda online-förvarings bitcoin-plånböcker på grund av bandbreddskostnader. Med en låg bandbredd kan endast en mobil mobilklient fungera som ett mellansteg mot att så småningom köra en dedikerad full nod.

En fördel med förvaring av bitcoin-utbyten är att deras risker för användarnas integritet och medel är mycket lika de hos andra betrodda betalningsleverantörer som PayPal och Western Union. Lätta klientplånböcker kräver en mer nyanserad uppskattning av säkerhets- och integritetsavvägningar som kommer från att använda anonyma offentliga noder och komplexa peer-to-peer-protokoll..

Det finns också ett argument att lätta klienter i allmänhet kan vara skadliga för Bitcoin-nätverket. När fler människor driver lätta klienter ökar kraven på bandbredd och beräkning av de offentliga fullnoderna som tjänar dem. Detta kan leda till en minskning av antalet offentliga fullnoder, särskilt de som tjänar information till lätta kunder. Om alla lätta klienter litar på en liten uppsättning offentliga fullnoder kan deras säkerhet och integritet äventyras om de fullständiga noder konspirerar mot dem.

Vi tror att påverkan på Bitcoin-nätverket kan minimeras om lätta kunder också utbyter data direkt med andra lätta kunder. Spridningen av lätta klienter kommer så småningom att leda till att fler användare kör fulla noder, särskilt i utvecklingsländer där anslutning är dyrare och persondatorer inte används i stor utsträckning.

Nätverkslager

Lätta klienter måste stödja många av samma nätverksprotokolllager som Bitcoin-fulla noder. Båda börjar med att direkt kommunicera med en första uppsättning Bitcoin-noder. Från dessa initiala noder byter de adresserna till andra noder som ingår i Bitcoin-nätverket.

Både lätta klienter och fullständiga noder måste också lära av sina kamrater om bevis på arbetet som säkrar och ansluter alternativa blockchain-tips till genusblocket. Hela noder skiljer sig främst från lätta kunder när det gäller hur de delar information om transaktioner. Fullständiga noder utbyter information om transaktioner i block och validerar självständigt att nya block följer Bitcoins konsensusregler. Lätta klienter bekräftar bara specifika transaktioner finns i block som bekräftas av fullständiga noder.

Anslutning

Till skillnad från fasta fasta internetanslutningar som vanligtvis används för hela noder använder mobiltelefoner uppmätta internetanslutningar där överföring av stora mängder data kan vara kostsamt. Mobiltelefoner tar också slut på batterier som förbrukas snabbare vid överföring av data. De kan inte heller dra direkt nytta av sändningsdataflöden som kräver fasta parabolantenner eller stora radioantenner.

Mobila enheter har viss flexibilitet och integritetsfördelar jämfört med noder med fast ström och dataanslutningar. De kan fungera utanför nätet eller under strömavbrott och i vissa områden kan de köpa förbetalda internetabonnemang anonymt. Mobila enheter kan också få integritet och censurmotstånd genom att ansluta till olika lokala kamrater via ad-hoc-nätverk när de rör sig runt.

Lätta klienter gjorda för mobiltelefoner bör tillåta användare att konfigurera hur mycket mobil bandbredd de ska använda och vara medvetna om när datatilldelningar förnyas eller snart går ut. Alternativa omätade lokala anslutningar, som en WiFi-hotspot, bör användas opportunistiskt när de är tillgängliga för bandbreddsintensiva uppgifter som att ladda ner block för att bevara uppmätt bandbredd.

Kamrater

Både fulla noder och lätta klienter förlitar sig på en robust peer discovery process för att säkerställa att de ansluter till en mängd olika ärliga peer-noder. Bitcoin-noder ansluter initialt till förinställda frönoder men måste alltid upptäcka nya kamrater för att hålla kontakten med det ”ärliga” Bitcoin-nätverket. Programvaran Bitcoin Core med full nod har utvecklat robust heuristik för att mildra förmörkelseattacker från skadliga kamrater och koppla från noder som inte fungerar bra. Eftersom peer-adresser endast är 30 byte vardera kan lätta klienter använda samma heuristik som fullständiga noder för att ofta fråga flera kollegor efter nya adresser.

Det bästa sättet att förhindra att isoleras från det ärliga Bitcoin-nätverket är att upprätthålla en stor, ihållande och mångsidig uppsättning peer-anslutningar. För att bevara batteriets livslängd bör lätt klientprogramvara vara noga med att inte väcka en mobiltelefon för ofta för att skvallra om peer-adresser eller utföra andra uppgifter. Lätta klienter ska synkronisera med sina kamrater vid samma fasta tidsintervall för att minimera både batterianvändning och kopplingar från kollegor.

Blockera rubriker

Både fullständig nod- och lättklientsäkerhet beror på förmågan att upptäcka blockkedjans kedjespets med mest arbete för att säkra den. Denna process börjar med att fråga alla kamrater för den senaste blockera rubriker de känner till för blockchain. En nod kan behöva fråga sina kamrater på olika punkter för att hitta den punkt när de först håller med om vilken kedjegaffel som är korrekt. Lätta klienter bör också validera bevis på arbete, tidsstämpel, Merkle-rot och föregående rubrikblock-hash för varje blockhuvud som de får och förbjuda kamrater som serverar ogiltiga blockrubriker. Fullständiga noder validerar också rubriker innan block laddas ner för att förhindra DoS-attacker (Denial-of-Service).

När den kanoniska kedjespetsen har bestämts kan en lätt klient synkronisera blockhuvuden för att säkerställa att kedjespetsen ansluts till Bitcoin-genesblocket – cirka 50 MB data. Vissa lätta klienter som använder långsamma eller uppmätta anslutningar kan initialt bara ladda blockrubriker tillbaka till en kontrollpunkt istället för Genesis-blocket. Hela noder ska alltid synkronisera alla blockrubriker. Användare bör varnas för risken att acceptera betalningar tills hela sidhuvudkedjan har kontrollerats. Lätta klienter och fullständiga noder måste fortsätta ladda ner 80 byte blockrubriker från varje kollega för att hålla sig synkroniserade med blockkedjan när den växer och även fråga flera kollegor för blockrubriker för att säkerställa att de alltid följer den nuvarande bästa blockrubriken.

Moderna lätta klientplånböcker kan upptäcka när en transaktion de spårar visas i ett block med BIP-157 blockera filter. Liksom blockrubriker frågar lättklienter också sina kamrater för att bestämma den aktuella spetsen för en filterhuvudkedja. BIP-157 lättklienter laddar ned 32 byte-blockfilterhuvuden per block för att förbli synkroniserade med blockfilterhuvudkedjan. I händelse av oenighet mellan kamrater om rätt filterhuvudkedja kan lättklienter ladda ner motsvarande block för att avgöra vilken kamrat som följer rätt kedja. Lätta klienter bör ignorera blockfilterkedjor som innehåller ogiltiga rubriker och kollegor med svartlistor som visar ogiltiga block- eller filterhuvuden.

Blockfilter ger större integritet än det utfasade BIP-37 blomfiltersystem eftersom ljusklienter inte läcker till en hel nod vilka transaktioner de är intresserade av. Blockfilter skalas också bättre än blomfilter. Eftersom endast ett blockfilter genereras per block, behöver en hel nod bara en konstant mängd beräkning för att tjäna flera lätta klientkompisar. Ljusa klienter själva kan också hjälpa till att vidarebefordra blockfilter och skvallerblockfilterhuvuden för att öka antalet lätta klientkompisar som varje fullständig nod stöder.

En lätt klient kräver åtminstone blockfiltret för block som kan innehålla relevanta transaktioner. Filter är cirka 15 kB per block, så för en transaktion som tar sex block (cirka en timme) att bekräfta, skulle en lätt klient behöva ladda ner 90 kB filterdata för att få en indikation på vilket block transaktionen visas i. I fall av ett andra lager protokoll som Blixtnätverk, perioden för att se efter en transaktion skulle vara öppen såvida inte Vakttornen används. Vakttorn är särskilt användbara för lätta kunder på mobila enheter, både för att de sannolikt kommer att vara offline under långa perioder och eftersom de är begränsade för bandbredd.

Transaktioner

Endast block-fullständig nod

För att minska förbrukningen av bandbredd kan hela noder konfigureras att användas endast block-läge för att ladda ner hela block, men inte skvaller om transaktioner. Detta är ett säkert och privat sätt att bekräfta transaktioner och kräver inte blockfilter eftersom varje block laddas ner. En mobil klient som fungerar som en beskäras block-endast full nod kräver upp till 2 GB nedladdningsbandbredd per vecka. En mobil klient med snabbt och billigt eller omätbart internet kan fungera i detta läge för att få säkerhets- och integritetsfördelarna med att köra en hel nod, men stöder fortfarande lätt klientläge när bandbredd mäts eller batteriström är begränsad. Flexibiliteten för en mobil lättklient att opportunistiskt fungera som en block-enbart full nod kan bidra till att öka antalet fulla noder i länder där persondatoranvändning är mindre vanligt. Mobila block-endast-fulla noder kan också betjäna blockfilter för ljusklienter utan att avsevärt öka deras egen bandbreddsanvändning.

Blockera Filter Light Client

Det nya BIP-157 blockfiltersystemet laddas ned strippad block på upp till 1 MB endast när en spårad transaktion detekteras i kedjan av nedladdade blockfilter. Detta är en stor förbättring jämfört med de 2 GB per vecka av bandbredd som behövs för att se efter transaktioner med en enda Bitcoin-fullnod. Nedladdade block kan användas för att validera blockfilter, ogiltiggöra blockfilterkedjor och koppla bort från kamrater som delar ogiltiga filter. Detta skapar ett sätt för lätta klienter att förhindra ogiltiga filterkedjor från att spridas och gör det möjligt för lätta klienter att dela filterinformation med varandra och minska belastningen på hela noder. Lätta klienter kan fråga hela uppsättningen hela noder för nya block, inte bara fulla noder som serverar blockfilter. Detta förhindrar läckande information om de transaktioner som en lätt klient är intresserad av och sprider belastningen bland en större uppsättning fulla noder.

Lätta klienter som använder BIP-157 blockfilter bekräftar inte självständigt att alla transaktioner i ett block följer Bitcoins konsensusregler, utan antar istället att kedjan som bekräftas av mest hash-kraft följer rätt regler. Dessa noder kan luras till att följa en majoritet av gruvarbetare som samarbetar för att anta olika utgiftsregler. I en situation som SegWit2x kontroversiell hård gaffel kunde en lätt klientanvändare ha vilts om att acceptera en ogiltig betalning från en gaffel i Bitcoin blockchain. Klientanvändare med låg bandbredd är också mer mottagliga för en mängd förmörkelseattacker som är lättare att dölja än en gruvarbetad hårdgaffel. Användare av protokoll från andra lagret som Lightning Network är också potentiellt sårbara för låg kostnad tidsutvidgningsattacker.

Electrum Light Client

En annan populär lösning för lätta enheter är Electrum klient-serverprotokoll. Istället för att ladda ner blockfilter och block från fullständiga noder för att bekräfta transaktioner, an Electrum lätt klientplånbok begär små Merkle bevis för specifika transaktioner (refereras av ett unikt transaktions-ID) direkt från en eller flera servrar som kör Electrum-protokollet. Eftersom Electrum-servrar kan logga de exakta transaktionerna som begärs av varje lättklient är det viktigt att klienter anonymiserar sina förfrågningar med hjälp av en Tor lök service eller liknande tjänster. Det är möjligt att många av de nuvarande offentliga Electrum-servrarna drivs av privata kedjeövervakningsföretag i syfte att samla in data för att deanonymisera Bitcoin-transaktioner. En ytterligare risk att förlita sig på Electrum-servermodellen är att serveroperatörer skadligt kan hålla tillbaka (censur) som tillhandahåller bevis för vissa transaktioner, vilket är svårare att göra enligt BIP-157-modellen..

Medan det finns många färre offentliga Electrum-servrar än Bitcoin-fulla noder, tjänar för närvarande mycket få fulla noder blockfilter till lätta klienter. Detta förväntas förändras eftersom BIP-157 blockfilterstöd nu har varit sammanslagna in i Bitcoin Core-programvaran.

En Electrum-baserad ljusklient skulle behöva ännu mindre bandbredd än en blockfilterbaserad ljusklient eftersom den inte behöver ladda ner blockfilterhuvuden, blockfilter eller avdragna hela block för att bekräfta transaktioner. Istället behöver Electrum-klienter bara begära ett Merkle-bevis på cirka 400 B för att bekräfta varje transaktion.

Sammanfattning

Tabellen nedan sammanfattar hur mycket uppmätt data som skulle användas av en block-enbart full nod, en blockfilterbaserad ljusklient och en Electrum-baserad ljusklient. Som du kan se i sammanfattningen använder antingen typ av ljusklient dramatiskt mindre bandbredd per vecka än till och med en minimal block-endast full nod.

Datastorlek Peers frågade Returnerade värden Endast block-fullständig nod Blockera Filter Light Client Electrum Light Client
Peer-adresser 30 B 8 1000 234 kB 234 kB 234 kB
Blockhuvuden för aktuell kedjespets 80 B 8 1 640 B. 640 B. 640 B.
Filterhuvuden för filterkedjespets 32 B 8 1 – 256 B –
Blockera rubriker tillbaka till Genesis Block 80 B 1 650 000 50 MB 50 MB 50 MB
Nya blockrubriker (1 vecka) 80 B 8 1008 630 kB 630 kB 630 kB
Nya blockfilter (1 vecka) 15 kB 1 1008 – 15 MB –
Blockerar tillbaka till Genesis Block 1 till 1,5 MB 1 650 000 200 GB – –
Nya block (1 vecka) ~ 2 MB 1 1008 2 GB – –
Block per transaktion 1 MB 1 1 – 1 MB –
Merkle-bevis per transaktion ~ 400 B. 1 1 – – 400 B.
Max initial synk 200 GB 50 MB 50 MB
Max per vecka 2 GB 15 MB 630 kB
Max per transaktion – 1 MB 400 B.

Blixt

En mobil blixtklient kan använda en lättklient som beskrivs ovan för att skapa, stänga och övervaka blixtkanaler. En mobil Lightning-klient kan också minska bandbredden den använder för att skvallra om nätverksvägar och istället använda lokal routing för att rendezvous eller trampolin Blixtnoder. När en Lightning-kanal har förankrats i Bitcoin blockchain, behöver uppdateringar till kanalen inte tillgång till internet utan bara en direkt peer-to-peer-dataförbindelse till kanalpartner. Övervakningskanaler för ridbyxor kan konfigureras för att matcha hur ofta en lätt klient har internetåtkomst. Finansieringstransaktionen för kanaler kan också periodiskt förankras / skarvas om den bandbredd som krävs för att uppdatera Vakttorn skulle vara dyrare än en enda transaktion på kedjan. Att förhandla kanaluppdateringsriktning med kamrater över ett LAN eller radioanslutning kan också öka motståndskraften, minska mätad internetanvändning och öka integriteten.

Användare av Layer 2-protokoll som Lightning som övervakar och reagerar på kanalöverträdelser med hjälp av lätta klienter är potentiellt mer utsatta för lågkostnadsattacker som t.ex. tidsutvidgning eller flod-och-loot. En lätt klient kan inte ta reda på intrångstransaktioner förrän de visas i ett block eftersom de inte skvaller om väntande transaktioner. Lätta klienter kan också vara lättare att förmörka om de litar på en liten grupp kamrater för blockfilter.

Exempel

För dessa exempel beskriver vi hur en lätt klient kan användas för att skicka och ta emot både bitcoinbetalningar via kedjan och med Lightning:

On-Chain

För att bekräfta att en transaktion har mottagits i blockchain måste en lätt klient genomföra följande steg:

  1. Synkronisera blockhuvuden med den aktuella kedjespetsen
  2. Synkronisera filterrubriker med den aktuella kedjespetsen
  3. Skicka en transaktion till en fullständig nod för inkludering i ett block
  4. Synkronisera blockfilter från den punkt transaktionen skickas till en fullständig nod
  5. När ett blockfilter matchar transaktionen, ladda ner motsvarande strippade block

I det här exemplet antar vi att blockhuvuden och blockfilterhuvuden redan har synkroniserats till genesblocket. Detta kräver initialt 50 MB data och cirka 1 MB per vecka därefter för att hålla sig synkroniserad med den aktuella kedjespetsen från flera kamrater. Mängden data som behövs för att åter synkronisera blockrubriker (1) och blockera filterrubriker (2) till det aktuella blockchain-tipset efter en tid offline beror på hur nyligen denna information senast har uppdaterats.

Nedladdning av blockfilter (4) för att titta efter en viss transaktion beror på hur snabbt transaktionen bekräftar. Det finns en avvägning mellan att betala låga transaktionsavgifter och att använda mer bandbredd för att ladda ner blockfilter. För en timmes blockfilter krävs endast nedladdning av 90 KB filterdata. Den största fasta datakostnaden för lätta klienter är att ladda ner ett strippat block som motsvarar blockfiltret som matchar transaktionen de är intresserade av. Detta kräver upp till 1 MB blockdata per transaktion. Om flera intressanta transaktioner uppträder i samma block kräver detta bara nedladdning av ett block.

Även användare med dyra eller långsamma mobildata bör kunna bekräfta Bitcoin-transaktioner från sin mobiltelefon med detta system om de har råd med 1 MB data per transaktion och 1 MB per vecka för att hålla sig synkroniserade med blockchain.

”När det gäller dina uppskattningar; Om det kan genomföras skulle det vara relevant och ekonomin med det skulle kunna driva fler bitcoinanvändare till egenförvar, säger utvecklaren Emmanuel Ndangurura från Nairobi, Kenya. Emmanuel noterade att en dataplan på 175 MB som inte går ut, eller en veckobunt på 500 MB, kan köpas i Nairobi för endast $ 0,50. Med hjälp av datauppskattningarna ovan, med endast 175 MB, kan en användare ladda ner en 50 MB-app, synkronisera blockrubriker och fortfarande ha data för att skicka och ta emot betalningar på ett privat och självförvarande sätt med hjälp av blockfilter.

Blixt

En blixtnod måste utföra stegen på kedjan som beskrivs ovan för att öppna kanaler, stänga kanaler och svara på kanalbrott. De måste också komma åt en internetanslutning för följande:

  1. Monitor för felaktig kanal stängs med hjälp av någon av följande tekniker:
    • a) Prenumerera på och skicka möten till Vakttornen för varje kanaluppdatering
    • b) Ladda ner blockfilter för hela perioden Blixtkanaler är öppna
    • Få skvaller för nätverkstopologi för källruttning
    • Förhandla Lightning-protokollet direkt med kanalpartner

    Till skillnad från transaktioner via kedjan behöver Bitcoin-nätverket inte nås för varje Lightning-betalning. Istället måste lätta klienter få åtkomst till Bitcoin-kollegor inom ett konfigurerbart tidsfönster (t.ex. en vecka) för att kontrollera att deras motpart inte har försökt att på ett falskt sätt stänga kanalen med ett äldre kanaltillstånd. Idealt skulle kanaltillståndsövervakning kunna utföras när en omätad anslutning är tillgänglig. För situationer där endast dyra uppmätta anslutningar är tillgängliga, är användning av Watchtowers (6a) överlägsen för övervakning av kanaltillstånd. Klienter som inte övervakar blockchain (6b) riskerar emellertid att förlora pengar om deras Vakttorn inte reagerar på kanalbyxor.

    Vakttorn (6a) skulle kräva något i storleksordningen 500 B per blixtbetalning som görs av eller dirigeras genom en kollega för att skickas till en Vakttorn via en internetport. Detta är mycket mindre än att övervaka direkta transaktioner (6b), vilket kräver nedladdning av cirka 15 MB blockfilterdata per vecka. En kanal kan också stängas samarbetsvilligt eller återförankrad / skarvad on-chain innan övervakningsfönstret löper ut om det skulle vara billigare ur en bandbredds- eller vakttorners prenumerationssynpunkt.

    Istället för att skvallra om nätverkstopologi (7), bör lätta klienter använda privata blixtnoder och inte dirigera betalningar för andra där bandbredd är dyrt. Istället bör de använda trampolin routing eller liknande stegvisa routing tekniker. Detta skulle minska bandbreddsanvändningen på bekostnad av dirigeringssekretess.

    För att faktiskt förhandla om en kanaluppdatering (8) krävs så lite som 2 kB per betalning gjord av noden eller vidarebefordrad för en kollega. Kanaluppdateringar kan göras mellan noder i samma lokala nätverk även när internet-gateways inte är tillgängliga.

    En mobil blixtnod skulle behöva 1 MB bandbredd för varje kanal de skapar eller stänger on-chain. De skulle behöva 2 KB för att förhandla om varje kanaluppdatering och ytterligare 500 B för att registrera varje uppdatering med en Watchtower eller 15 MB per vecka för att övervaka blockchain direkt med blockfilter.

    Slutsats

    Mobillätta klienter kan avsevärt öka säkerheten för Bitcoin-användare som för närvarande är beroende av vårdtagande Bitcoin-plånböcker. Nya blockfilterbaserade ljusklienter tillåter användare med så lite som 2 MB bandbredd per vecka för att bekräfta transaktioner via kedjan.

    Genom att använda Vakttorn kan mobila blixtnoder utföra många lågavgiftsaffärer utan att kräva mer uppmätt bandbredd än nuvarande onchain-transaktioner. Eller blixtnoder kan använda blockfilter för att oberoende övervaka blockchain med mindre än 20 MB per vecka.

    Mobillätta klienter kan också opportunistiskt dra nytta av obegränsad internetåtkomst för att fungera som beskurna block-endast-fulla noder i ”endast mobila” delar av världen. Vi tror att fokus på Bitcoin-klienter med låg bandbredd kommer att bidra till fördelarna med självhushållning till fler av världen och så småningom leda till större geografisk mångfald av Bitcoin-fulla noder.

    Särskilt tack till Karim Helmy och Kommer Clark för användbara diskussioner och för att läsa utkast till denna artikel; tack också till Alejandro Machado för hans uppmuntran att fortsätta detta projekt.