## Jak se bitcoinové nody hledají a jak se sítí šíří transakce

Když Satoshi Nakamoto navrhl Bitcoin, nevytvořil pouze jeho popis, ale také první implementaci. Díky tomu Bitcoin neskončil v situaci připomínající babylonskou věž, kdy by vznikla řada vzájemně nekompatibilních implementací, které by spolu nedokázaly komunikovat.

Dnes existuje více implementací bitcoinového nodu, ale všechny musí dodržovat společná konsenzuální pravidla. Právě ta určují, které bloky a transakce síť považuje za platné. Pokud by se dvě implementace v těchto pravidlech zásadně rozešly, přestaly by být součástí stejné bitcoinové sítě.

Dominantní implementací je stále Bitcoin Core. Vedle něj existují i další, například Bitcoin Knots. Rozdíly mezi nimi se mohou týkat politiky mempoolu, relayování transakcí nebo výchozí konfigurace, ale pokud mají zůstat součástí stejné sítě, musí se shodnout na konsenzu.

### Jak nový node najde ostatní

Představme si nový bitcoinový node jako člověka, který chce přijít na party. Nejdřív musí zjistit, kde se party koná. Jakmile se tam dostane a pozná několik lidí, může od nich získat kontakty na další účastníky.

Velmi podobně funguje první připojení bitcoinového nodu.

Čerstvě spuštěný Bitcoin Core ještě nezná žádné jiné nody. Má proto zabudovaný seznam takzvaných **DNS seedů**. Jde o pevně zadané domény, jejichž DNS servery vracejí IP adresy bitcoinových nodů, které jsou v danou chvíli dostupné.

Samotné názvy DNS seedů jsou v programu pevně zakódované, ale IP adresy, které vracejí, se průběžně mění. Nový node se tak může rychle dozvědět o několika existujících účastnících sítě a začít s nimi komunikovat.

Pokud by DNS seedy nebyly dostupné, existuje ještě záložní mechanismus s předem známými adresami.

Jakmile však node jednou naváže spojení a získá informace o dalších účastnících sítě, už při příštím spuštění nemusí začínat znovu od DNS seedů. Známé adresy si ukládá lokálně, mimo jiné do souboru `peers.dat`, a při restartu se nejprve pokusí spojit s některými dříve známými nody.

DNS seed je tedy především mechanismus pro počáteční bootstrap. Jakmile je node součástí sítě, dokáže si svou databázi peerů dále udržovat sám.

### Kdo provozuje DNS seedy

DNS seedy obvykle provozují dlouholetí členové bitcoinové komunity a vývojáři jednotlivých implementací.

Jejich role je poměrně citlivá. Software totiž musí nějak rozhodnout, kterým seedům bude při prvním spuštění důvěřovat. Proto bývají vybírány služby provozované lidmi, kteří jsou v projektu dlouhodobě známí a jejichž provoz lze do určité míry kontrolovat.

Různé implementace přitom nemusejí používat úplně stejný seznam seedů. To je jedna z oblastí, kde se mohou jejich politiky lišit, aniž by se tím měnila konsenzuální pravidla Bitcoinu.

### První rozhovor dvou nodů

Když se dva bitcoinové nody spojí, nejprve musí zjistit, zda spolu vůbec dokážou komunikovat.

Na začátku spojení si vymění zprávu `version`. Název může působit dojmem, že obsahuje pouze číslo verze programu, ale ve skutečnosti obsahuje více informací.

Patří mezi ně například:

- verze protokolu,
- podporované služby a funkce, například SegWit,
- časová značka,
- síťová adresa,
- náhodná hodnota nonce,
- výška blockchainu, kterou node deklaruje,
- informace o tom, zda chce přijímat relayované transakce.

Nonce slouží mimo jiné k tomu, aby node dokázal rozpoznat situaci, kdy by se omylem připojil sám k sobě.

Deklarovanou výšku blockchainu nelze v této fázi považovat za důvěryhodnou informaci. Protistrana může tvrdit v zásadě cokoli. Skutečný stav blockchainu se ověřuje až vlastní validací dat.

Po výměně úvodních zpráv oba nody vědí, jakou verzi protokolu protistrana používá a které funkce podporuje.

Bitcoinový protokol je přitom navržen tak, aby si v rozumné míře zachovával zpětnou kompatibilitu. Pokud spolu komunikují dvě různé verze nodu, mohou používat tu část protokolu, které rozumějí obě.

### Výměna adres: „Koho ještě znáš?“

Po připojení může nový node požádat svého peera o seznam dalších známých nodů.

V podstatě se zeptá:

„Koho ještě znáš?“

K tomu slouží zpráva `getaddr`. Protistrana může odpovědět seznamem síťových adres pomocí zpráv `addr`, případně novějšího formátu `addrv2`.

Tím se velmi rychle rozšiřuje množina nodů, o kterých nový účastník sítě ví. Není tedy potřeba získávat všechny adresy z jednoho centrálního místa.

Bitcoinová síť zároveň používá princip podobný **gossip protokolu**. Když se node dozví o nových adresách, může některé z nich předávat dál dalším peerům. Informace se tak sítí postupně šíří, podobně jako drby mezi lidmi.

### Addrman: adresář známých nodů

Bitcoin Core si známé síťové adresy spravuje pomocí interní struktury označované jako **addrman**.

Nejde pouze o jednoduchý seznam IP adres. Adresy jsou organizovány tak, aby bylo obtížnější zaplnit databázi velkým množstvím nodů ovládaných jedním útočníkem.

To je důležité kvůli takzvanému **Sybil útoku**.

Při něm se útočník snaží vytvořit velké množství zdánlivě nezávislých nodů. Pokud by oběť získávala peery pouze náhodným výběrem z jednoduchého seznamu, mohl by útočník seznam zahltit svými vlastními adresami a výrazně zvýšit pravděpodobnost, že se oběť připojí právě k nim.

Addrman proto adresy rozděluje do skupin a bucketů mimo jiné podle jejich síťového původu. Útočníkovi tak nestačí provozovat tisíce nodů v jednom datacentru nebo na jednom rozsahu IP adres. Aby databázi skutečně ovládl, potřeboval by nody rozmístěné napříč mnoha různými částmi internetu.

Tím se podobný útok podstatně komplikuje.

### Inbound a outbound spojení

Bitcoinový node může mít dva základní typy spojení: **outbound** a **inbound**.

Outbound spojení navazuje sám node na jiné nody. Inbound spojení naopak přicházejí zvenčí od dalších účastníků sítě.

Maximální počet spojení lze konfigurovat. Z hlediska bezpečnosti jsou velmi důležitá především outbound spojení, protože jejich protistrany si node vybírá sám.

Pokud by útočník dokázal ovládnout všechna relevantní spojení oběti, mohl by provést **eclipse attack**.

### Eclipse attack

Při eclipse útoku se útočník snaží oběť úplně izolovat od zbytku bitcoinové sítě.

Napadený node pak sice může mít několik zdánlivě normálních spojení, ale všechny vedou pouze k nodům ovládaným útočníkem. Ten může rozhodovat, které informace oběť dostane a které nikoli.

Aby takový útok uspěl, musí se útočník dostat do dostatečně velké části adresáře známých nodů a následně obsadit spojení, která si oběť vytvoří.

Bitcoin Core používá několik mechanismů, které to komplikují. Vedle běžných dlouhodobých spojení například vytváří krátkodobá **feeler connections**. Pomocí nich si může ověřovat další nody mimo svou aktuální množinu dlouhodobých peerů a mimo jiné porovnat deklarovanou výšku blockchainu.

Díky kombinaci těchto mechanismů je úplná izolace nodu poměrně obtížná.

## Jak se sítí šíří transakce

Jakmile máme vysvětleno, jak se nody navzájem nacházejí a propojují, můžeme se podívat na druhou část problému: jak se nová bitcoinová transakce dostane od uživatele až k minerovi.

Běžný bitcoinový node neposílá transakci přímo konkrétnímu minerovi. Výjimkou by samozřejmě byla speciální konfigurace, kdy by měl uživatel explicitně nastavené spojení na konkrétní node nebo infrastrukturu těžaře.

Za normálních okolností funguje opět gossip.

Node vytvoří nebo přijme novou transakci a oznámí její existenci svým peerům. Ti ji mohou převzít a informovat o ní další nody. Transakce se tak postupně šíří přes peer-to-peer síť, až se dostane také k nodům provozovaným těžaři.

### Nejprve pouze identifikátor

Bitcoinové nody neposílají každému peerovi automaticky celou transakci.

Nejprve typicky oznámí pouze její identifikátor pomocí inventory mechanismu. Protistrana tak zjistí, že existuje nová transakce.

Pokud ji ještě nemá a chce ji získat, vyžádá si její data.

Je to jednoduchá síťová optimalizace. Nemá smysl posílat celý payload transakce nodu, který ji již dávno zná.

Gossip protokol tedy nefunguje stylem „každý okamžitě pošle všechno všem“. Informace se šíří postupně a nody si přenášejí samotná data pouze tehdy, když je potřebují.

### Více spojení nemusí znamenat rychlejší propagaci

Mohlo by se zdát, že čím více outbound spojení node má, tím rychleji se jeho transakce rozšíří sítí.

Ve skutečnosti to není tak jednoduché.

Bitcoin Core zavádí při relayování transakcí určité náhodné časování. Transakce nejsou všem peerům oznamovány přesně ve stejném okamžiku.

Jedním z důvodů je ochrana soukromí.

Kdyby node po vytvoření nové transakce okamžitě a současně informoval všechny své sousedy, bylo by snazší sledovat síť a odhadnout, kde konkrétní transakce vznikla.

Náhodné zpoždění a postupné šíření tento druh síťové analýzy komplikují.

Existují nody, jejichž účelem je síť především sledovat. Připojují se k velkému množství peerů a pozorují, odkud a kdy se jednotlivé transakce objevují. I právě proti takovému monitorování se některé mechanismy relayování snaží poskytovat alespoň částečnou ochranu.

## Globální mempool neexistuje

Jedním z častých nedorozumění je představa, že Bitcoin má jeden globální mempool.

Nemá.

**Mempool je lokální stav každého konkrétního nodu.**

Když například webová služba ukáže, že určitou transakci vidí v mempoolu, znamená to pouze, že se transakce dostala k nodu nebo infrastruktuře dané služby. Neznamená to automaticky, že ji už znají všechny nody sítě nebo že se dostala ke všem těžařům.

Každý node se navíc sám rozhoduje, které nekonfirmované transakce bude ve svém mempoolu uchovávat.

A právě zde se dostáváme k rozdílu mezi **konsenzuálními pravidly** a **relay/mempool policy**.

### Konsenzus versus policy

Konsenzuální pravidla určují, zda je transakce platná z pohledu blockchainu. Pokud miner vloží do bloku transakci, která tato pravidla porušuje, ostatní nody blok odmítnou.

Vedle toho ale existuje ještě lokální politika jednotlivých nodů.

Node může říci:

„Tato transakce by sice v bloku byla konsenzuálně platná, ale do svého mempoolu ji přijímat nechci.“

Může například vyžadovat minimální poplatek nebo uplatňovat jiné limity.

To je zásadní rozdíl. Transakce může být **validní**, ale přesto se kvůli relay policy sítí prakticky nešířit.

### Minimální relay fee

Typickým příkladem je minimální poplatek, při kterém je node ochoten transakci přijmout a dál relayovat.

Historicky byla velmi dlouho běžná hodnota kolem 1 sat/vB. Postupně se začaly používat i nižší hodnoty.

Změna takového výchozího nastavení však neznamená, že se ve stejném okamžiku změní celá bitcoinová síť. Každý provozovatel může mít jinou verzi Bitcoin Core a jinou konfiguraci.

Vzniká tedy přechodné období, kdy některé nody transakce s velmi nízkým fee přijímají a jiné je odmítají.

Pokud je dostatečná část sítě ochotna takové transakce relayovat, mohou se přesto dostat až k těžaři.

## RBF a problém s incremental relay fee

Ještě zajímavější situace nastává u **Replace-by-Fee (RBF)**.

RBF umožňuje nahradit nekonfirmovanou transakci jinou verzí s vyšším poplatkem. Aby však node náhradní transakci přijal, musí splnit nejen běžné podmínky pro relay, ale také pravidla vztahující se přímo k nahrazování transakcí.

Jedním z nich je **incremental relay fee**.

V určitém období tak mohlo dojít k situaci, kdy byl minimální poplatek pro nové transakce snížen, ale parametry ovlivňující RBF zůstaly nastaveny výše.

Výsledkem bylo poněkud matoucí chování.

Nová transakce s velmi nízkým fee se mohla sítí šířit bez problémů. Když ji ale uživatel chtěl nahradit pomocí RBF jen o něco dražší transakcí, některé nody ji kvůli své mempool policy odmítly.

Zvenčí přitom nemuselo být vůbec zřejmé, co se stalo. Jeden node mohl transakci přijmout na síťové vrstvě, ale jeho mempool ji následně kvůli lokálním pravidlům nepřijal. Transakce se potom dál nešířila a nemusela se dostat k těžařům.

To pěkně ukazuje, proč je při zkoumání propagace bitcoinových transakcí potřeba rozlišovat několik různých otázek:

Je transakce konsenzuálně platná?

Přijme ji konkrétní node do svého mempoolu?

Bude ji relayovat svým peerům?

A existuje v síti dostatečně propojená cesta přes nody s kompatibilní politikou, aby se transakce dostala až k minerovi?

Odpověď na každou z těchto otázek může být jiná.

## Peer-to-peer síť bez centrálního seznamu

Na bitcoinové síti je pozoruhodné, že celý tento mechanismus funguje bez centrálního registru nodů.

Nový node začne s několika málo kontakty. Od nich získá další adresy, průběžně je testuje, ukládá si je, třídí a vytváří nová spojení.

Informace o dalších nodech i nové transakce se potom šíří prostřednictvím gossip mechanismů.

Síť zároveň používá několik vrstev ochrany proti manipulaci: strukturované ukládání adres v addrmanu, nezávislá outbound spojení, feeler connections a další opatření, která ztěžují Sybil a eclipse útoky.

A přestože základní princip fungování bitcoinové peer-to-peer sítě existuje už mnoho let, její implementace se stále vyvíjí.

To je ostatně pro Bitcoin typické. Na základních konsenzuálních pravidlech musí existovat velmi silná shoda, ale kolem nich zůstává poměrně velký prostor pro experimentování: jak vybírat peery, jak efektivněji šířit informace, jak nastavovat mempool policy nebo jak zlepšovat ochranu soukromí a odolnost proti síťovým útokům.

Bitcoin tak není jedna homogenní aplikace běžící na tisících počítačů. Je to síť nezávislých nodů, které si samy vybírají své sousedy, samy validují přijímaná data a samy rozhodují, co budou dále šířit.

A právě to je jedna z vlastností, díky nimž může celá síť fungovat bez centrální autority.