120 / 736CMPCT

Compact Blocks

Kompaktní přenos bloků

Většinu transakcí nového bloku už sousední uzel často zná. Compact Blocks místo opakovaného posílání celého obsahu pošlou návod k jeho sestavení a doplní, co chybí. Kontrola výsledku zůstává stejně přísná.

Compact Blocks jsou způsob, jak podle BIP 152 předávat bitcoinové bloky s menším množstvím opakovaných dat. Nezmenšují samotný blok ani neuvolňují jeho pravidla: příjemce musí obnovit celý obsah a před přijetím jej ověřit.

Anna chce Petrovi poslat nový blok. Blok sdružuje transakce do dávky, která se připojuje ke společné historii. Jenže mnoho jeho transakcí Petr už má, takže by posílala stejné údaje podruhé. Compact Blocks mu raději předají hlavičku bloku a seznam krátkých značek, podle kterých najde známé transakce. Hlavička je krátká část bloku se základními údaji, včetně odkazu na předchozí blok a kontrolního otisku transakcí. Pro technického čtenáře: značky mají 48 bitů, tedy 6 bajtů, a vznikají zkrácením výsledku funkce SipHash-2-4. Její parametry se odvozují z hlavičky a přidaného čísla nonce pro tento přenos. Značka proto není trvalým názvem transakce pro celou síť Bitcoin. [1] [2] [7]

Ne všechno lze nahradit seznamem. Anna pošle vybrané transakce v úplném znění spolu s jejich pozicí v bloku. Běžným příkladem je Coinbase Transaction, první transakce bloku, která přiděluje těžařskou odměnu; nesouvisí s burzou stejného jména. Vzniká přímo pro daný blok, takže ji Petr zpravidla nemá v zásobě čekajících transakcí. Úplné položky a krátké značky se při skládání navzájem doplňují. [1] [2]

Petrův Mempool je místní soubor transakcí, které jeho uzel zná, ale zatím je nemá potvrzené v přijatém řetězci. Pro dostupné transakce vypočítá stejné krátké značky a hledá shody se seznamem od Anny. Nespoléhá se na to, že všichni mají totožnou zásobu. A protože krátká značka může výjimečně odpovídat více transakcím, samotná shoda ještě není konečným důkazem správného obsahu. [1] [2]

Když zůstanou některá místa prázdná nebo nejednoznačná, Petr požádá o konkrétní transakce podle jejich pozic. Síťová zpráva s požadavkem se jmenuje getblocktxn, odpověď s transakcemi blocktxn. Názvy si není třeba pamatovat: podstatné je vyžádat si skutečná data místo odhadování obsahu. Další cesta zprávy tam a zpět stojí čas; při neúspěšné rekonstrukci lze stáhnout celý blok. [1] [3]

Petr musí obnovit přesné transakce ve správném pořadí a zkontrolovat jejich vazbu na hlavičku. Merkle Tree je struktura, která shrnuje transakce do kontrolního otisku a pomáhá takové vazby ověřit. Ani správné poskládání ale nenahrazuje kontrolu pravidel. Full Node je program, kterým Petr samostatně ověřuje pravidla Bitcoinu, například oprávnění utratit prostředky a výši odměny. Digitální podpis dokládá oprávnění k platbě pomocí soukromého klíče, tajného číselného údaje, aniž by jej odhalil. Kompaktní přenos mu nedává výjimku pro neplatný blok. [1] [8]

Přes zprávu sendcmpct se sousední uzly dohodnou na režimu. V rychlé variantě přijde zpráva cmpctblock s údaji pro složení bloku rovnou jako oznámení novinky. Odesílatel po stanovených předběžných kontrolách smí začít přenos dříve, než dokončí všechny kontroly transakcí. Musí mimo jiné ověřit návaznost na ověřený řetězec, Proof of Work, tedy důkaz výpočetní práce, a vazbu hlavičky na transakce. Příjemce přesto blok plně ověří před přijetím do své historie. [1] [4]

Druhá varianta nejprve oznámí existenci již ověřeného bloku zprávou inv nebo headers. Petr pak kompaktní data vyžádá, pokud je potřebuje. Může tak zabránit zbytečné zásilce bloku, který už získal jinudy, za cenu dalšího komunikačního kroku. Oba režimy mohou šetřit oproti opakovanému přenosu všech transakcí; liší se tím, kdy a bez jakého předchozího dotazu data posílají. Nejde o dvě úrovně platnosti bloku. [1] [7]

Dvě různé transakce mohou mít stejnou krátkou značku. Tomu se říká kolize. Připomíná to dva lidi se stejnými iniciálami: zkratka už nestačí k rozlišení. Software si vyžádá upřesnění nebo přejde na úplný blok podle toho, kde problém vznikl. Kolize není prolomením bitcoinových podpisů a nemění neplatný blok na platný. Zkontrolovat musí skutečný obsah, nikoli pouze shodu krátkých značek. [1] [2]

Verze 2 kompaktního protokolu podporuje SegWit, úpravu oddělující podpisová a další ověřovací data do části witness. Používá wtxid, identifikátor zahrnující i tato data, místo txid, který je nezahrnuje. Úplné transakce přenáší i s potřebnými witness daty podle BIP 144. Nejde tedy o jejich vynechání, aby zásilka vypadala menší. Číslo verze přenosového protokolu navíc není číslem verze samotného bloku. [1] [6]

Pokud mají Anna a Petr mnoho transakcí společných, blok projde sítí s výrazně menším množstvím opakovaného přenosu. To pomáhá i domácímu připojení při náhlém příchodu bloku. Při malém překryvu zásob přibude dožádání a úspora klesá. Hlavním cílem je omezit přenosová data; rychlejší doručení je možný přínos, nikoli záruka nulového čekání či jedné pevné velikosti zprávy. Bitcoin tím nedostává nový limit velikosti bloků. [5] [7]

Pro nejúplnější obraz čtěte toto heslo společně s Block Propagation, Initial Block Download, Eclipse Attack, vByte, Bitcoin, Coinbase transakce. Opačným směrem na něj odkazují také Stale Block, Eclipse Attack, Selfish Mining, Block Propagation.

DOC · 001BIP 152 — Compact Block RelaySpecifikace DOC · 002Bitcoin Core — BIP 152 implementationDokumentace DOC · 003Bitcoin Developer Reference — P2PDokumentace DOC · 004Bitcoin Core v29.0 — net processingDokumentace DOC · 005Bitcoin Optech — Compact block relayDokumentace DOC · 006BIP 144 — SegWit peer servicesSpecifikace DOC · 007Bitcoin Core — Compact Blocks FAQDokumentace DOC · 008Bitcoin Developer Guide — Block ChainDokumentace
Revidováno: Primární zdroje · Nejde o investiční doporučení