napsali Gloria Zhao a Murch

Všechny publikované části naší týdenní série o přeposílání transakcí, začleňování do mempoolu, výběru transakcí k vytěžení a o důvodech, proč má Bitcoin Core přísnější pravidla než jaká stanoví konsenzus a jak těchto pravidel mohou peněženky efektivně využít.

  1. K čemu je mempool?
  2. Incentivy
  3. Aukce blokového prostoru
  4. Odhad poplatků
  5. Pravidla pro ochranu zdrojů uzlů
  6. Konzistence pravidel
  7. Síťové zdroje
  8. Pravidla jako rozhraní
  9. Návrhy pravidel
  10. Zapojte se

K čemu je mempool?

Původně vyšlo ve zpravodaji č. 251

Množství uzlů v bitcoinové síti ukládá nepotvrzené transakce v memory poolu (tj. v předem alokovaném znovupoužitelném bloku paměti); odtud „mempool.” Tato mezipaměť je důležitým zdrojem každého uzlu, který umožňuje peer-to-peer přeposílání transakcí.

Uzly, které se přeposílání transakcí účastní, stahují a validují bloky postupně. Uzly bez mempoolu zaznamenávají každých zhruba deset minut špičku v datovém přenosu následovanou výpočetně náročnou validací každé transakce. Na druhou stranu uzly s mempoolem již mají pravděpodobně v mempoolu všechny transakce z bloku uložené. Díky přeposílání kompaktních bloků mohou tyto uzly stáhnout pouze hlavičku bloku spolu se zkrácenými identifikátory a následně blok rekonstruovat z transakcí v mempoolu.

Množství přenášených dat je v případě používání kompaktních bloků v porovnání s velikostí celého bloku minimální. Validace transakcí probíhá rychleji, neboť uzel již ověřil a uchoval elektronické podpisy a skripty, spočítal požadavky časových zámků a načetl z disku související UTXO. Tento uzel může také okamžitě přeposlat blok svým spojením a tím dramaticky zvýšit rychlost propagace bloku. Rychlost rozšiřování bloku po síti snižuje riziko objevení zastaralých bloků.

Mempooly mohou též sloužit k nezávislému odhadování poplatků. Trh s prostorem pro bloky je aukcí založenou na poplatcích, mempool tak dává uživatelům lepší přehled o nabídkách ostatních účastníků a poskytuje historii nabídek.

Neexistuje však žádný globální, sdílený mempool; každý uzel může přijímat jiné transakce. Zaslání transakce jednomu uzlu neznamená, že se nakonec dostane k těžařům. Někteří uživatelé považují tuto nejistotu za frustrující a táží se, proč nelze transakce zasílat přímo těžařům.

Představme si bitcoinovou síť, ve které jsou všechny transakce posílány od uživatelů přímo těžařům. Bylo by snadné donutit několik malých subjektů k logování IP adres odpovídajících jednotlivým transakcím a tím cenzurovat transakce a sledovat finanční toky. Takový bitcoin by se možná používal pohodlněji, ale postrádal by některé z nejdůležitějších vlastností.

Soukromí a odolnost vůči cenzuře jsou vlastnosti vycházející z peer-to-peer sítě. Aby mohly uzly transakce přeposílat, mohou se připojit k anonymní množině uzlů, z nichž každý by mohl být těžař nebo někdo k těžařovi připojený. Tento způsob pomáhá zmást stopy k uzlu, od kterého transakce pochází a který ji potvrdil. Cenzor by mohl cílit na některé těžaře, populární směnárny či jiné centralizované služby, ale bylo by náročné blokovat zcela všechno.

Přístup k nepotvrzeným transakcím dále pomáhá minimalizovat vstupní náklady zahájení produkce bloků: kdokoliv nespokojený s výběrem transakcí (nebo jejich vylučováním) se může okamžitě stát dalším těžařem. Považovaní všech uzlů za rovnocenné při zveřejňování transakcí odpírá těžařům výsadní přístup k transakcím a jejím poplatkům.

Mempool je mimořádně užitečná mezipaměť, která umožňuje uzlům rozložit v čase náklady na stahování a validaci bloků a která dává uživatelům přístup k lepšímu odhadování poplatků. Na úrovni sítě podporují mempooly distribuci transakcí a bloků. Všechny tyto výhody jsou nejvýraznější v případě, kdy každý vidí všechny transakce před tím, než je těžaři začlení do bloků. Jako kterákoliv jiná mezipaměť, i mempool je nejužitečnější, když je často používaný. Musí být také omezen na velikosti, aby mohl být obsažen v paměti. Příští týden se podíváme na slučitelnost pobídek jako metriku držení nejužitečnějších transakcí v mempoolech.

Incentivy

Původně vyšlo ve zpravodaji č. 252

Minulý příspěvek představil mempool jako mezipaměť nepotvrzených transakcí, která uživatelům poskytuje decentralizovaný způsob posílání transakcí těžařům. Avšak těžaři nejsou povinni tyto transakce potvrdit, blok obsahující pouze coinbasovou transakci je podle pravidel konsenzu zcela validní. Uživatelé mohou těžařům poskytnout podnět k začlenění transakcí navýšením celkové hodnoty vstupů bez navýšení celkové hodnoty výstupů. Tento rozdíl si mohou těžaři vzít jako poplatek za transakci.

I když jsou v tradičním finančním světě transakční poplatky běžné, noví bitcoinoví uživatelé jsou často překvapeni, že poplatky za umístění v blockchainu nejsou úměrné hodnotě transakce, ale její váze. Namísto likvidity je omezujícím faktorem blokový prostor. Jednotkový poplatek se obvykle uvádí v jednotkách satoshi za virtuální byte.

Pravidla konsenzu v každém bloku omezují celkový prostor využitý transakcemi. Díky tomuto omezení jsou časy propagace bloků nízké v porovnání s intervalem produkce bloků a riziko zahození bloků je tak nižší. Též napomáhá k omezení nárůstu blockchainu a množiny UTXO, tedy vlastností, které přímo přispívají k nákladům na udržování plného uzlu.

Mempooly díky své roli mezipaměti nepotvrzených transakcí též zprostředkovávají veřejnou dražbu neelastického blokového prostoru. Pracuje-li správně, funguje tato dražba na principu volného trhu, tedy priorita je stanovena čistě jen na poplatcích a ne na vztazích s těžaři.

Maximalizace poplatků při výběru transakcí do bloku (který je limitován celkovou váhou a počtem operací podepisování) je NP-těžký problém. Tento problém dále ztěžují vztahy mezi transakcemi. Těžba transakce s vysokým jednotkovým poplatkem může být podmíněna těžbou jeho rodiče s nízkým poplatkem. Nebo, vzato z jiného úhlu, výběr transakce s nízkým jednotkovým poplatkem může otevřít příležitost k těžbě potomka s vysokým jednotkovým poplatkem.

Mempool v Bitcoin Core počítá jednotkový poplatek pro každou položku a jeho předky (tzv. jednotkový poplatek předků, „ancestor feerate”), ukládá tento výsledek do mezipaměti a sestrojuje šablony bloků pomocí hladového algoritmu. Seřazuje mempool v pořadí dle hodnocení předků („ancestor score”; jedná se o minimum z jednotkového poplatku předků a vlastního jednotkového poplatku), vybírá balíčky předků v tomto pořadí a za chodu upravuje informace o poplatcích a váhách předků zbývajících transakcí. Tento algoritmus nabízí rovnováhu mezi výkonností a ziskovostí, avšak nemusí poskytnout optimální výsledky. Jeho účinnost může být zvýšena omezením velikosti transakcí a balíčků předků; Bitcoin Core stanovuje tyto limity na 400 000, resp. 404 000 váhových jednotek.

Podobně se počítá i hodnocení potomků („descendant score”), které se používá při výběru balíčků, které mají být z mempoolu vyhozeny. Bylo by nevýhodné vyhodit transakce s nízkým poplatkem, které mají potomky s vysokým poplatkem.

Validace mempoolu též používá poplatky a jednotkové poplatky při nakládání s transakcemi, které utrácejí shodné vstupy. Těmto případům se též říká dvojí utrácení nebo konfliktní transakce. Uzly neakceptují vždy jen první transakci, kterou spatří, ale aplikují soubor pravidel, aby určily, které transakce je výhodnější ponechat. Toto chování je známé jako nahrazení poplatkem („replace by fee”).

Je zřejmé, že těžaři chtějí maximalizovat poplatky, avšak proč by měly netěžící uzly též implementovat tato pravidla? Jak bylo zmíněno v minulém příspěvku, užitečnost mempoolů netěžících uzlů je přímo navázána na jejich podobnost s mempooly těžařů. I když se provozovatelé uzlů nechystají produkovat bloky z obsahu svých mempolů, držení nejvýhodnějších transakcí je i v jejich zájmu.

I když neexistují žádná pravidla konsenzu vyžadující platbu poplatků, hrají poplatky a jednotkové poplatky v bitcoinové síti důležitou roli ve „spravedlivém” způsobu řešení soutěže o blokový prostor. Těžaři využívají jednotkové poplatky k posuzování přijímání, vyhazování a řešení konfliktů a netěžící uzly se drží tohoto chování, aby maximalizovaly užitečnost svých mempoolů.

Vzácnost blokového prostoru tlačí velikost transakcí směrem dolů a ponouká vývojáře k lepší efektivitě konstrukce transakcí. Příští týden prozkoumáme praktické strategie a techniky minimalizace transakčních poplatků.

Aukce blokového prostoru

Původně vyšlo ve zpravodaji č. 253

Minulý týden jsme zmínili, že transakce neplatí poplatky dle přenášené hodnoty, ale za použitý prostor v bloku. Také jsme vysvětlili, že těžaři vybírají transakce takový způsobem, aby poplatky činily co největší částku. Vyplývá z toho, že v nově nalezeném bloku jsou potvrzeny pouze transakce z vrcholu mempoolu. V tomto příspěvku popíšeme strategie optimalizace poplatků. Předpokládáme, že máme vyhovující zdroj odhadu výše jednotkového poplatku (příští týden si povíme více o odhadování jednotkového poplatku).

Během konstrukce transakcí jsou některé její součásti flexibilnější než jiné. Každá transakce musí mít hlavičku, výstupy (určené jednotlivými platbami) a výstup pro drobné. Odesílatel i příjemce by měli upřednostňovat takové typy výstupů, které jsou efektivní z hlediska využitého prostoru, aby snížili budoucí náklady na utracení svých výstupů. Konečnou podobu a váhu však dává transakci výběr vstupů. Jelikož transakce mezi sebou soutěží jednotkovým poplatkem (poplatek / váha), lehčí transakce vyžadují k dosažení stejného jednotkového poplatku nižší celkový poplatek.

Některé peněženky, například Bitcoin Core, se snaží zkombinovat vstupy takovým způsobem, aby se zcela vyhnuly nutnosti vytvářet výstup s drobnými. To vede nejen ke snížení váhy nyní, ale také ke snížení budoucích nákladů utracení tohoto výstupu. Bohužel takové kombinace vstupů jsou jen zřídka možné, pokud peněženka nemá k dispozici velké množství UTXO s různorodými částkami.

Moderní druhy výstupů jsou prostorově efektivnější než starší typy. Například utracení P2TR vstupu přispěje méně než dvěma pětinami váhy P2PKH vstupu (viz kalkulátor velikosti transakce). Multisig peněženky mohou těžit z nedávno dokončeného schématu MuSig2 a protokolu FROST, díky kterým mohou být multisig operace kódovány způsobem, který připomíná běžný vstup s jedním podpisem. Peněženky používající moderní druhy výstupů mohou obzvláště v době vysoké poptávky po blokovém prostoru dosáhnout vysokých úspor.

Přehled vah vstupů a výstupů

Chytré peněženky mění strategii výběru na základě jednotkového poplatku: při vyšších jednotkových poplatcích dosahují použitím méně vstupů a moderních druhů vstupů nejnižší možnou váhu pro danou množinu vstupů. Vybírat pokaždé nejlehčí množinu vstupů by sice minimalizovalo náklady na tuto aktuální transakci, ale také by štěpilo zásobu UTXO na malé fragmenty. To by si později mohlo vynutit transakce s příliš velkou množinou vstupů v době s vysokým jednotkovým poplatkem. Je tedy prozíravé, aby peněženky v dobách s nízkým jednotkovým poplatkem také vybíraly více těžších vstupů, aby dosáhly konsolidace prostředků do menšího množství moderních výstupů a tím se připravily na pozdější vysokou poptávku po blokovém prostoru.

Vysoce používané peněženky často slučují několik plateb do jediné transakce, aby dosáhly snížení váhy transakce na platbu. Vyhnou se tak platbě za hlavičku a výstup pro drobné za každou platbu; namísto toho všechny platby sdílí tento náklad pouze jednou. Sloučení několika málo plateb rychle snižuje náklady za platbu:

Úspory za sloučení plateb v P2WPKH

I když mnoho peněženek jednotkový poplatek nadsazuje, někdy transakce čeká na potvrzení déle, než se plánovalo. V takových případech může odesílatel nebo příjemce změnit transakci prioritu.

Uživatelé mají zpravidla k dispozici dva nástroje, které jim pomohou navýšit prioritu transakce: CPFP (child pays for parent, potomek platí za předka) a RBF (replace by fee, nahrazení poplatkem). V případě CPFP utrácí uživatel svůj výstup, aby tím vytvořil potomka této transakce, který bude mít vyšší jednotkový poplatek. V minulém příspěvku jsme si vysvětlili, že je v zájmu těžařů vybrat rodičovskou transakci do bloku, aby mohl být začleněn i její potomek s vysokým poplatkem. CPFP je dostupné každému, komu je platba v transakci směrována, čili buď příjemce nebo odesílatel (pokud vytvořil i výstup pro drobné).

V případě RBF připraví odesílatel transakci s vyšším jednotkovým poplatkem, která nahradí transakci původní. Nahrazující transakce musí použít alespoň jeden vstup shodný s původní transakcí; tento konflikt zaručí, že pouze jediná z těchto dvou transakcí bude začleněna do blockchainu. Obvykle tato nahrazující transakce obsahuje platby z původní transakce, ale odesílatel by též mohl prostředky přesměrovat jinam či zkombinovat platby z více transakcí do jedné. V minulém příspěvku jsme popsali, že uzly vyloučí původní transakci z mempoolu, neboť je pro ně výhodnější začlenit nahrazující transakci.

I když je poptávka i produkce blokového prostoru mimo naši kontrolu, mají peněženky k dispozici mnoho prostředků, kterými mohou dosáhnout efektivního využití blokového prostoru. Peněženky mohou ušetřit na poplatcích vytvářením lehčích transakcí eliminací výstupu pro drobné, utrácením nativních segwit výstupů a defragmentací svého UTXO setu v době nízkých poplatků. Peněženky, které podporují CPFP a RBF, mohou také začít s konzervativnějším jednotkovým poplatkem a bude-li potřeba, mohou transakci pomocí CPFP nebo RBF navýšit prioritu.

Odhad poplatků

Původně vyšlo ve zpravodaji č. 254

Minulý týden jsme prozkoumali techniky minimalizace poplatků placených za transakci při daném jednotkovém poplatku. Avšak jaký by tento jednotkový poplatek měl být? Nejlépe co nejnižší, abychom ušetřili peníze, ale dostatečně vysoký, aby nám zajistil místo v bloku podle uživatelovy časové preference.

Cílem odhadu (jednotkového) poplatku je převést cílený časový rámec pro konfirmaci na nejnižší jednotkový poplatek, který by transakce měla zaplatit.

Jednou z komplikací odhadu poplatku je nepravidelnost produkce blokového prostoru. Řekněme, že aby obdržel zboží, potřebuje uživatel obchodníkovi zaplatit během jedné hodiny. Uživatel očekává, že každých deset minut bude vytěžený jeden blok, a tak bude cílit pozici uvnitř příštích šesti bloků. Avšak je možné, že jeden z bloků bude nalezen až za 45 minut. Odhady poplatků musí vzít do úvahy uživatelovu naléhavost nebo časový rámec (ve smyslu „chci, aby byla tato transakce potvrzena do konce pracovního dne”) a nabídku blokového prostoru (počet bloků). Aby se s těmito obtížemi algoritmy odhadování poplatků vypořádaly, vyjadřují cíle konfirmací v čase i počtu bloků.

Naivní odhad poplatku lze postavit na historických údajích o výši poplatků, které postačují na začlenění do bloků. Jelikož takový odhad nezahrnuje transakce čekající v mempoolech na potvrzení, dosahoval by velmi nepřesných výsledků v dobách s neočekávaně vysokou fluktuací poptávky po blokovém prostoru a občasných dlouhých intervalech mezi bloky. Další slabostí je závislost na informacích zcela ovládaných těžaři, kteří by mohli dosáhnout zvyšování poplatků začleňováním falešných transakcí s vysokými jednotkovými poplatky do svých bloků.

Naštěstí trh blokového prostoru není aukcí naslepo. V našem prvním příspěvku jsme zmínili, že vedení mempoolu a účast v P2P síti přeposílání transakcí umožňuje uzlu vidět nabídky ostatních uživatelů. Odhad poplatků v Bitcoin Core používá k výpočtu pravděpodobnosti začlenění transakce s poplatkem f v příštích n blocích i historická data, avšak zaměřuje se hlavně na výšky, ve kterých uzel transakci poprvé zaznamená a kdy se potvrdí. Tato metoda ignoruje aktivitu, která se děje mimo veřejný trh. Pokud těžaři začleňují do svých bloků transakce s uměle nafouknutými poplatky, tento odhad poplatků by tím ovlivněn nebyl, neboť používá jen data transakcí, které byly před potvrzením veřejně šířeny.

Dále máme dobrý přehled o způsobu vybírání transakcí do bloků. V předchozím příspěvku jsme zmínili, že uzly emulují pravidla těžařů, aby ve svých mempoolech držely výhodné transakce. Díky tomu můžeme postavit algoritmus odhadu poplatků, který simuluje chování těžařů. Abychom nalezli jednotkový poplatek, za který by byla transakce potvrzena během příštích n bloků, mohli bychom díky použití algoritmu sestavování bloků a vlastního mempoolu navrhnout příštích n bloků a spočítat, jaký poplatek by porazil poslední transakce, které by se dostaly do bloku n.

Je zřejmé, že účinnost tohoto odhadu poplatků závisí na podobnosti obsahu našeho mempoolu a mempoolu těžařů, což nikdy nelze zaručit. Dále nemůže zohlednit transakce, které těžař může začlenit na základě externích podnětů, např. vlastní těžařovy transakce či transakce, jejíž poplatky za potvrzení byly zaplaceny jiným způsobem. Algoritmus také musí zohlednit dodatečné transakce, které se objeví. Může tak učinit snížením velikosti navržených bloků, ale o kolik?

Tato otázka opět vyzdvihuje užitečnost historický dat. Chytrý model může zahrnout vzory aktivity a zohlednit vnější události ovlivňující poplatky jako jsou pracovní doba, plánované konsolidace UTXO či reakce na změny ceny bitcoinu. Problematika předpovídání poptávky po blokovém prostoru je a nadále zůstane předmětem studií a zkoumání.

Odhadování poplatků je mnohostranný a složitý problém. Špatný odhad může přivést plýtvání prostředky, zhoršit použitelnost bitcoinu pro placení a způsobit ztrátu peněz uživatelům vrstev nad bitcoinem, kteří kvůli nevhodnému poplatku zmeškají okno časového zámku UTXO. Dobrý odhad poplatků umožňuje uživatelům jasně a přesně sdělovat těžařům naléhavost transakce a díky CPFP a RBF mohou aktualizovat své nabídky v případě podhodnocených původních odhadů. Díky pravidlům a politikám mempoolu zohledňujícím výhodnost transakcí, dobře navrženým nástrojům pro odhadování poplatků a peněženkám se mohou uživatelé účastnit efektivní veřejné aukce blokového prostoru.

Odhady poplatků obvykle nenabízí hodnoty pod 1 sat/vB, bez ohledu na délku časového horizontu či množství transakcí čekající na potvrzení. Mnozí považují 1 sat/vB za nejnižší jednotkový poplatek v bitcoinové síti, neboť většina uzlů (včetně těžařů) nikdy neakceptuje nic pod touto hodnotou. Příští týden prozkoumáme pravidla uzlu a další důvody pro zohledňování jednotkových poplatků přeposílaných transakcí: ochrana před vyčerpáním zdrojů.

Pravidla pro ochranu zdrojů uzlů

Původně vyšlo ve zpravodaji č. 255

Na počátku naší série jsme uvedli, že většina ochrany soukromí a odolnost vůči cenzuře pramení z decentralizace bitcoinové sítě. Uživatelé provozující uzly napomáhají k redukci počtu slabých míst, špehování a cenzury. Vyplývá z toho, že jedním z hlavních cílů designu software bitcoinového uzlu je jeho vysoká dostupnost. Pokud by byli uživatelé nuceni pořídit si drahý hardware, používat konkrétní operační systém nebo platit měsíčně stovky dolarů za jeho provozování, počet uzlů v síti by nejspíš klesl.

Navíc je takový uzel bitcoinové sítě připojen pomocí internetu k neznámým entitám, které mohou spustit útok odepření služby (DoS) a způsobit tím pád uzlu vyčerpáním paměti nebo plýtvání výpočetními a přenosovými zdroji. Jelikož jsou tyto entity anonymní, nemohou naše uzly před připojením určit, které uzly budou poctivé a které zlomyslné, a nemohou je ani po detekci útoku účinně zakázat. Je tedy nutné, aby byla implementována pravidla, která chrání před DoS a omezují náklady na provozování plného uzlu.

Všeobecné ochrany proti DoS a vyčerpání zdrojů jsou vestavěné přímo do software uzlů. Například obdrží-li Bitcoin Core od jediného spojení velké množství zpráv, zpracuje pouze první z nich, zbytek uloží do fronty a zpracuje je pouze, až obdrží a zpracuje zprávy od jiných spojení. Uzly také obvykle nejdříve stáhnou pouze hlavičku bloku, ověří její Proof of Work (PoW) a teprve potom stáhnou a ověří zbytek bloku. Útočník, který by chtěl vyčerpat zdroje uzlu v rámci přeposílání bloků, by tak nejdříve musel věnovat nepřiměřené množství vlastních zdrojů k výpočtu validního PoW. Tato asymetrie mezi obrovskými náklady na výpočet PoW a minimálními náklady na jeho ověření poskytuje přirozený způsob ochrany DoS v rámci přeposílání bloků. Tuto vlastnost však nemá přeposílání nepotvrzených transakcí.

Všeobecné ochrany proti DoS však neposkytují dostatečné překážky proti jiným druhům útoků. Útočník může například zbastlit maximálně výpočetně náročnou validní transakci, jako byla 1MB „megatransakce” v bloku 364292, jejíž validace trvala mimořádně dlouho dobu kvůli ověřování podpisů a kvadratickému sighashingu. Útočník může také za řadu validních podpisů přidat jeden nevalidní, kvůli čemuž stráví uzel nad transakcí několik minut, aby zjistil, že se jedná o zmetka. Během té doby uzel nepracuje na novém bloku. Můžeme si představit, že takový druh útoku by cílil na konkurenční těžaře, aby jim zpozdil počátek hledání nového bloku.

Ve snaze vyhnout se práci na výpočetně velmi náročných transakcích omezují uzly s Bitcoin Core maximální velikost a počet operací s podpisy (tzv. „sigops”) v každé transakci více, než jsou limity konsenzu. Uzly s Bitcoin Core také vynucují omezení na velikost balíčků předků a potomků, díky čemuž jsou produkce šablon bloků a algoritmy vylučování účinnější a výpočetní náročnost přidání do a odebírání z mempoolu nižší. I když kvůli těmto pravidlům mohou být vyloučeny některé validní transakce, očekává se, že podobné případy budou vzácné.

Tato pravidla jsou příklady pravidel přeposílání transakcí („transaction relay policy”), jež existují nad rámec pravidel konsenzu a týkají se nepotvrzených transakcí.

Ve výchozím stavu neakceptuje Bitcoin Core transakce s nižším jednotkovým poplatkem než 1 sat/vB („minrelaytxfee”), neověřují žádné podpisy před ověřením tohoto požadavku a nepřeposílají transakce, dokud nejsou přijaty do jejich vlastních mempoolů. Ve své podstatě stanovuje toto pravidlo minimální „cenu” za validaci a přeposílání. Netěžící uzly nikdy poplatky neobdrží, pouze těžař, který transakci potvrdí, dostane zaplaceno. Poplatky však přináší náklady útočníkovi. Kdo posílá extrémní množství transakci a „plýtvá” tak síťovými zdroji, brzy přijde platbou poplatků o všechny peníze.

Pravidla nahrazování poplatkem („replace by fee”) implementována v Bitcoin Core vyžadují, aby nahrazující transakce platila vyšší jednotkový poplatek než kterákoliv transakce, se kterou je v přímém konfliktu, a také aby celkový poplatek byl vyšší než poplatek za všechny transakce, které nahrazuje. Dodatečné poplatky vydělené virtuální velikostí nahrazující transakce musí být vyšší než 1 sat/vB. Jinými slovy, bez ohledu na jednotkový poplatek původní a nahrazující transakce musí nová transakce zaplatit „nové” poplatky, aby pokryla své vlastní přenosové náklady za cenu 1 sat/vB. Hlavní důvod tohoto pravidla je zdražit opakované útoky plýtvající přenosovým pásmem, např. takové, kdy každé další nahrazení přidává jediný satoshi.

Uzel, který kompletně validuje bloky a transakce, vyžaduje zdroje včetně paměti, výpočetních zdrojů a přenosového pásma. Musíme zajistit, aby požadavky na zdroje byly co nejnižší a aby tak bylo provozování uzlu přístupné a odolné vůči vykořisťování. Všeobecné DoS ochrany nejsou dostatečné, proto uzly vedle pravidel konsenzu aplikují během validace nepotvrzených transakcí navíc i pravidla přeposílání transakcí. Jelikož však pravidla nejsou konsenzem, dva uzly mohou mít pravidla nastavena odlišně a i tak mohou dojít ke shodě na stavu blockchainu. Příští týden popíšeme pravidla jako individuální volbu.

Konzistence pravidel

Původně vyšlo ve zpravodaji č. 256

Minulý týden jsme si představili soubor pravidel pro validaci transakcí používaných nad rámec pravidel konsenzu. Tato pravidla nejsou aplikována na transakce v blocích, uzel tedy může zůstat v konsenzu s ostatními, i když se jeho pravidla liší. Stejně jako se může provozovatel uzlu rozhodnout nepodílet se na přeposílání transakcí, může si též svobodně zvolit svá pravidla či žádná pravidla vůbec nevynucovat (a tím se vystavit riziku DoS). Z toho vyplývá, že nemůžeme předpokládat jednotnost mempoolů v síti. Avšak aby mohla být naše transakce přijata těžařem, musí nejdříve projít cestou uzlů, které ji přijmou do svých mempoolů; jakákoliv odchylka pravidel mezi těmito uzly má přímý dopad na přeposílání transakcí.

Hraničním příkladem odlišnosti pravidel mezi uzly budiž situace, ve které si každý provozovatel uzlu zvolí náhodné číslo, které bude jako jediné přijímat v nVersion. Jelikož by většina peer-to-peer relací měla nekompatibilní pravidla, transakce by se k těžařům nedostávaly.

Na druhou stranu shodná pravidla napříč sítí napomáhají sjednocování obsahu mempoolů. Síť se shodnými mempooly nejlépe přeposílá transakce a je též ideální pro odhad poplatků a přeposílání kompaktních bloků, jak bylo zmíněno v předchozích příspěvcích.

Vzhledem ke složitosti validace mempoolu a obtížím spojených s rozdílností pravidel je Bitcoin Core konzervativní v možnostech konfigurování pravidel. I když mohou uživatelé snadno nastavit způsob počítání sigops (bytespersigop) či omezit množství dat v OP_RETURN výstupech (datacarriersize a datacarrier), nemohou se bez změny kódu vyvázat z maximální standardní váhy 400 000 váhových jednotek či používat odlišný soubor pravidel pro RBF.

Některá z nastavení pravidel v Bitcoin Core existují pro přizpůsobení se odlišným provozním prostředím či důvodům provozování uzlu. Například těžařovy hardwarové zdroje a důvody pro držení mempoolu jsou odlišné od běžného uživatele provozujícího lehký uzel na laptopu nebo Raspberry Pi. Těžař může chtít navýšit kapacitu mempoolu (maxmempool) nebo čas expirace (mempoolexpiry), aby mohl během špičky ukládat transakce s nízkým jednotkovým poplatkem, které by mohl těžit v čase nižšího provozu. Webové stránky nabízející vizualizace, archívy či statistiky mohou provozovat několik uzlů, aby sbíraly co nejvíce dat a zobrazovaly výchozí chování mempoolu.

Co se týče jednotlivých uzlů, nastavení kapacity mempoolu ovlivňuje dostupnost nástrojů k navýšení poplatků. Roste-li minimální jednotkový poplatek mempoolu kvůli vysokému počtu příchozích transakcí, nemohou být poplatky navyšovány pomocí CPFP transakcím vyloučeným z mempoolu či transakcím novým majícím jednotkový poplatek pod tímto minimem.

Na druhou stranu, jelikož vstupy odstraněných transakcí už nejsou utráceny žádnou transakcí v mempoolu, může být nově možné navýšit poplatek pomocí RBF. Nová transakce ve skutečnosti v mempoolu nic nenahrazuje, nemusí tedy uvažovat běžná pravidla RBF. Avšak uzly, které původní transakci z mempoolu neodstranily (kvůli vyšší kapacitě), považují tuto novou transakci za možnou nahrazující transakci a vynucují pravidla RBF. Pokud odstraněná transakce nesignalizovala možnost nahrazení (BIP125) či poplatek nové transakce nesplňuje kritéria RBF navzdory vysokému jednotkovému poplatku, nemusí těžař tuto novou transakci akceptovat. Peněženky musí s odstraněnými transakcemi nakládat opatrně, neboť výstupy transakce nemohou být pokládány za utratitelné a rovněž vstupy jsou podobně nedostupné k dalšímu použití.

Na první pohled se může zdát, že díky větší kapacitě mempoolu je pro uzel CPFP užitečnější a RBF méně užitečné. Avšak přeposílání transakcí je předmětem aktuálního chování sítě a cesta od uživatele k těžařovi, ve které všechny uzly toto CPFP akceptují, nemusí existovat. Uzly běžně přeposílají transakce až po akceptování do vlastního mempoolu a ignorují oznámení o transakcích, která již ve svém mempoolu mají. Uzly, které ukládají více transakcí, se chovají jako černé díry, když se k nim tyto transakce dostanou. Dokud celá síť nenavýší kapacitu svých mempoolů, což by bylo signálem pro změnu výchozí hodnoty, přinese navýšení kapacity jednotlivým uživatelům jen málo výhod. Minimální jednotkový poplatek mempoolu omezuje ve výchozím stavu užitečnost používání CPFP během špiček. Uživatel, jehož CPFP transakci vlastní uzel přijme díky navýšené kapacitě, si nemusí všimnout, že tuto transakci nikdo jiný nepřijal.

Síť přeposílání transakcí sestává z jednotlivých uzlů, které se k síti dynamicky připojují a odpojují. Každý z nich musí sám sebe chránit před zneužitím. Proto nemůžeme zaručit, že se každý uzel dozví o každé nepotvrzené transakci. Zároveň bitcoinové síti prospívá, konvergují-li uzly ke shodné množině pravidel přeposílání transakcí, díky které mají mempooly stejnorodý obsah. Příští článek osvětlí, jaká pravidla byla přijata pro co nejlepší fungování celé sítě.

Síťové zdroje

Původně vyšlo ve zpravodaji č. 257

Předchozí článek popisoval ochrany zdrojů uzlu. Jelikož mohou být zdroje u každého uzlu jedinečné, mohou být konfigurovatelné. Též jsme přednesli argumenty, proč je lepší konvergovat k jednomu souboru pravidel. Co by však mělo být součástí těchto pravidel? Tento článek vysvětlí koncept celosíťových zdrojů kritických pro škálovatelnost, aktualizovatelnost a přístupnost nastartování a udržování plného uzlu.

Jak bylo popsáno v předchozích příspěvcích, distribuovaná struktura bitcoinové sítě je zásadní pro dosažení jeho ideologických cílů. Peer-to-peer podstata bitcoinu umožňuje, aby pravidla sítě vyvstávala z hrubého konsenzu voleb jednotlivých provozovatelů uzlů, a omezuje pokusy o získání nepatřičného vlivu v síti. Tato pravidla jsou vynucována jednotlivě každým uzlem ověřujícím každou transakci. Různorodá a zdravá populace uzlů vyžaduje, aby byly náklady na provozování uzlů nízké. Je náročné škálovat v globálním měřítku jakýkoliv projekt, ale činit tak bez obětování decentralizace je jako bojovat s jednou rukou za zády. Bitcoin se snaží o udržení rovnováhy nekompromisní ochranou svých sdílených síťových zdrojů: množiny UTXO, datové stopy na blockchainu spolu s výpočetními nároky vyžadované na jejich zpracování a systém evoluce protokolu.

Není nutné znovu připomínat celou válku o velikost bloků, abychom si uvědomili, že omezení nárůstu blockchainu je nezbytné k zachování přístupnosti provozování vlastního uzlu. Na úrovni pravidel také existuje prostředek pro omezování růstu blockchainu v podobě minRelayTxFee, tedy minimálního poplatku nutného pro přeposlání transakce ve výši 1 sat/vbyte. Toto pravidlo zajišťuje existenci minimálních nákladů k omezení „bezmezné poptávky po trvalém vysoce replikovaném úložišti.”

Původně se pro sledování stavu sítě uchovávaly všechny transakce, které měly neutracené výstupy. Nově představená množina UTXO jako prostředek sledování prostředků přinesla významnou redukci dat. Od té doby se množina UTXO stala ústřední datovou strukturou. Vyhledání UTXO tvoří hlavní podíl všech přístupů do paměti, obzvláště během prvotního stahování bloků. Bitcoin Core již pro UTXO mezipaměť používá optimalizovanou datovou strukturu, avšak velikost množiny UTXO určuje, jaká její část se do mezipaměti nevměstná. Větší množina UTXO znamená více cache miss, což zpomaluje validaci bloků, prvotní stahování a validaci transakcí. „Dust limit” je příkladem pravidla, které omezuje tvorbu neutratitelných UTXO, jejichž hodnota je nižší než náklady na utracení. I přes to se „prachové bouře” s tisíci transakcemi objevily dokonce i v roce 2020.

Když se použití bare multisigu stalo populárním způsobem publikování dat na blockchainu, upravila se definice standardní transakce, aby jako alternativu povolovala jeden OP_RETURN výstup. Lidé si uvědomili, že by bylo nemožné zabránit uživatelům v publikování dat na blockchainu, avšak alespoň by tato data, uložena v neutratitelných výstupech, nemusela být navždy udržována v množině UTXO. Bitcoin Core 0.13.0 přinesl volbu -permitbaremultisig, která umožňuje uživatelům odmítnout nepotvrzené transakce obsahující výstupy s bare multisig.

I když pravidla konsenzu povolují ve výstupech jakékoliv skripty, Bitcoin Core přeposílá pouze několik známých vzorů skriptů. Díky tomu je snazší porozumět dopadům na síť, včetně nákladů na validaci a upgrade protokolu. Například transakce se vstupním skriptem obsahujícím op-kódy, P2SH vstupem s více než 15 podpisy nebo P2WSH vstupem, jehož witness by tvořil v zásobníku více než 100 položek, by všechny byly označeny za nestandardní. (Přehled pravidel obsahuje příklady a jejich motivace.)

Bitcoinový protokol je žijícím softwarovým projektem, který se musí nadále vyvíjet, aby odpovídal na budoucí potíže či potřeby uživatelů. Pro tento účel obsahuje konsenzus několik nepoužívaných děr („upgrade hooks”), jako je příloha („annex”), verze taprootových listů, verze witnessů, OP_SUCCESS a množství NOOP op-kódů. Avšak podobně jako absence centrálních bodů selhání brání útokům, vyžadují i celosíťové upgrady software koordinaci desítek tisíc nezávislých provozovatelů uzlů. Uzly nepřeposílají transakce, které používají některé z rezervovaných děr, dokud nebude jejich význam definován. Tento postup má odrazovat aplikace, aby nezávisle tvořily konfliktní standardy, což by vedlo k nemožnosti začlenit do konsenzu standard jedné aplikace bez zneplatnění standardu aplikace jiné. A pokud změna konsenzu nastane, uzly, které okamžitě neupgradují a tedy neví o nových pravidlech konsenzu, nemohou být přinuceny k akceptování zatím nevalidních transakcí do svých mempoolů. Tento způsob odrazování vede k dopředné kompatibilitě uzlů a umožňuje síti bezpečně upgradovat pravidla konsenzu bez nutnosti vyžadovat synchronizovanou aktualizaci software.

Jak můžeme vidět, používání pravidel k ochraně sdílených síťových zdrojů napomáhá k ochraně vlastností celé sítě a zároveň ponechává otevřené dveře k budoucímu vývoji protokolu. Také vidíme, jak třenice mezi růstem sítě a striktním omezením váhy bloků vedla k osvojení nejlepších postupů, dobrého technického designu a inovací. Příští týden prozkoumáme pravidla mempoolu jako vstupní brány protokolů druhé vrstvy a systémů chytrých kontraktů.

Pravidla jako rozhraní

Původně vyšlo ve zpravodaji č. 258

V této sérii jsme zatím prozkoumali motivace a záludnosti spojené s decentralizovaným přeposíláním transakcí, které vedou k lokální i globální poptávce po přísnějších pravidlech validace, než je konsenzus. Jelikož mohou mít změny pravidel přeposílání transakcí v Bitcoin Core dopad na přeposílání transakcí, vyžadují nejdříve dosažení společenského přijetí v rámci širší bitcoinové komunity. Podobně musí být i aplikace a protokoly na druhé vrstvě navrženy tak, aby se vyhnuly odmítání svých transakcí.

Protokoly s kontrakty jsou ještě závislejší na pravidlech spojených s prioritizací, protože vymahatelnost onchain závisí na možnosti mít transakce rychle potvrzené. V nepřátelském prostředí mohou mít podvádějící protistrany zájem na zdržení konfirmace, musíme tedy také uvažovat, jak by mohly být drobnosti v pravidlech přeposílání transakcí použity proti uživateli.

Transakce v lightning network se drží pravidel standardnosti zmíněných v předchozích článcích. Například jeho peer-to-peer protokol obsahuje ve zprávě open_channel volbu dust_limit_satoshis určující práh neutratitelnosti. Jelikož transakce obsahující výstup s hodnotou nižší než tento práh by nebyly uzly přeposlány, jsou tyto platby považovány za „nevymahatelné onchain” a jsou z commitment transakcí vyřazeny.

Protokoly s kontrakty často používají časové zámky, aby poskytly každému účastníkovi možnost zpochybnit stav publikovaný onchain. Pokud by transakce dotčeného uživatele nebyla potvrzena před uplynutím doby zámku, mohl by přijít o prostředky. Proto jsou poplatky extrémně důležitým nástrojem pro navýšení priority konfirmace. Odhad jednotkového poplatku je ztížen tím, že transakce budou zveřejněny v neznámém čase, uzly jsou často provozovány jako lehké klienty a některé možnosti navyšování poplatků nemusí být k dispozici. Například byl-li by jeden z účastníků LN kanálu offline, mohl by ten druhý jednostranně zveřejnit předem podepsanou commitment transakci a tím dosáhnout vyrovnání společných prostředků onchain. Žádná ze stran nemůže sama utratit společné UTXO, je-li tedy jedna strana offline, podepsání nahrazující transakce pro navýšení poplatku commitment transakce je nemožné. Namísto toho mohou commitment transakce obsahovat anchor výstupy, které pomohou účastníkům kanálu připojit v době zveřejnění potomka navyšujícího poplatek (CPFP).

Tento způsob navyšování poplatků má ale také svá omezení. Jak bylo zmíněno v předchozím příspěvku, přidání CPFP transakce není efektivní, pokud minimální jednotkový poplatek mempoolu přeroste poplatek commitment transakce. Musí tedy i tak být podepsány s mírně přeceněným jednotkový poplatkem pro případ navýšení minimálního poplatku mempoolu. Dále během vývoje anchor výstupů byly také zohledněny případy, kdy může být v zájmu jedné strany konfirmaci pozdržet. Například jedna strana (Alice) může zveřejnit svou commitment transakci před vypnutím uzlu. Pokud by byl jednotkový poplatek této commitment transakce příliš nízký pro dosažení okamžité konfirmace a pokud by Bob, Alicina protistrana, její transakci neobdržel, mohl by být zmaten, proč zveřejnění jeho verze commitment transakce není úspěšně propagováno v síti. Každá commitment transakce má dva anchor výstupy, takže každá strana může použít CPFP na kteroukoliv commitment transakci, například Bob může zkusit naslepo zveřejnit navýšení poplatku Aliciny verze commitment transakce, i když si není jist, zda předtím ona svou verzi zveřejnila. Každý anchor výstup disponuje malou hodnotou nad prahem neutratitelnosti. Po nějaké době ji může nárokovat kdokoliv jako opatření před zahlcením množiny UTXO.

Zaručit každé straně možnost navýšit poplatek transakce pomocí CPFP je však mnohem složitější, než přiřadit každé straně anchor výstup. Jak bylo zmíněno v předchozím příspěvku, jako ochranu před DoS omezuje Bitcoin Core počet a celkovou velikost potomků, kteří mohou být přiřazeni nepotvrzené transakci. Jelikož má každá protistrana možnost přidat potomky sdíleným transakcím, mohla by jedna z nich zablokovat CPFP transakci té druhé vyčerpáním tohoto limitu a tím jí zabránit v propagaci. Přítomnost těchto potomků tak v mempoolech „přišpendlí” tuto commitment transakci na pozici s nízkou prioritou.

Na zabránění tohoto potenciálního útoku je navrhováno, aby byly všechny ostatní výstupy omezeny relativním časovým zámkem, což by zabránilo v jejich utracení před konfirmací. Dále byla upravena pravidla v Bitcoin Core, aby bylo možné přidat ještě jednoho potomka (CPFP carve out), pokud je tento potomek malý a nemá žádné další předky. Tato kombinace změn v obou protokolech zajišťuje, že alespoň dva účastníci ve sdílené transakci by mohli v čase zveřejnění upravit jednotkový poplatek, aniž by významně navýšili možnost DoS útoku.

Zabránění CPFP naplněním omezení počtu potomků je příkladem pinning útoků. Tyto útoky zneužívají omezení v pravidlech mempoolu, aby transakcím zabránily v přístupu do mempoolu nebo v potvrzení. V tomto případě představují pravidla mempoolu kompromis mezi odolností vůči DoS a incentivami. Nějaký kompromis musí být učiněn: uzel by měl zvažovat navýšení poplatků, ale nemůže zpracovávat nekonečně mnoho potomků. CPFP carve out upravuje tento kompromis pro konkrétní případ použití.

Vedle vyčerpání limitu potomků existují i další pinning útoky, které zabraňují použití RBF, činí RBF příliš drahým či zneužívají RBF ke zpoždění konfirmace ANYONECANPAY transakcí. Pinning je problémem pouze v případech, kdy více stran spolupracuje na vytvoření společné transakce nebo kde má nedůvěryhodná strana prostor upravovat transakci. Minimalizace přístupu transakce nedůvěryhodným stranám je obecně dobrým způsobem vyhýbání se pinningu.

Tyto třecí plochy zdůrazňují nejen důležitost pravidel jako rozhraní pro aplikace a protokoly v rámci ekosystému bitcoinu, ale také ukazují místa, která potřebují vylepšit. Příští týden se podíváme na návrhy pravidel a otevřené otázky.

Návrhy pravidel

Původně vyšlo ve zpravodaji č. 259

Minulý příspěvek popsal anchor výstupy a CPFP carve out zajišťující, že kterákoliv strana kanálu může navýšit poplatek sdílené commitment transakce bez nutnosti spolupráce. Tento přístup stále obsahuje několik nevýhod: prostředky kanálu jsou svázané, aby mohly vytvořit anchor výstupy, jednotkový poplatek commitment transakce je většinou o trochu vyšší, aby byl vyšší než minimální poplatek mempoolu, a CPFP carve out povoluje pouze jednoho potomka navíc. Anchor výstupy nemohou zajistit podobnou dostupnost navýšení poplatků transakcí sdílených mezi více než dvěma stranami, jako je coinjoin nebo protokoly s více účastníky. Tento příspěvek zkoumá současné snahy adresovat tato i jiná omezení.

Přeposílání balíčků obsahuje P2P protokol a změny pravidel, které umožní transport a validaci skupin transakcí. Díky tomu by mohly být poplatky commitment transakcí navýšeny potomkem, i kdyby nesplňovaly požadavek minimálního jednotkového poplatku mempoolu. Dále by RBF balíčku umožnilo potomkovi navyšujícímu poplatek zaplatit za nahrazení transakcí, se kterými jsou jeho rodiče v konfliktu. Přeposílání balíčků je navrženo tak, aby odstranilo obecná omezení na základní vrstvě protokolu. Avšak díky jeho použití pro navyšování poplatků sdílených transakcí byly na jeho základě představeny pokusy o eliminaci pinningu v některých konkrétních případech. Například by RBF balíčku umožnil commitment transakcím nahrazení sebe navzájem, pokud by byly zveřejněny spolu se svými potomky navyšujícími poplatek. Díky tomu by nebylo potřeba mít v každé commitment transakci několik anchor výstupů.

Drobným zádrhelem je, že existující pravidla pro RBF vyžadují, aby nahrazující transakce platila vyšší absolutní poplatek než součet poplatků placených všemi nahrazovanými transakcemi. Toto pravidlo napomáhá prevenci odepření služby opakovanými nahrazeními, ale umožňuje záškodníkům zvýšit náklady na nahrazení transakce připojením potomka, který má vysoký poplatek, ale nízký jednotkový poplatek, což zamezuje transakci ve vytěžení. Tomuto druhu pinningu se často říká „pinning třetího pravidla.”

Vývojáři též navrhli zcela odlišné způsoby přidávání poplatků předem podepsaným transakcím. Například podepsání vstupů transakce s SIGHASH_ANYONECANPAY | SIGHASH_ALL by umožnilo odesílateli transakce poskytnout poplatek připojením dodatečných vstupů, avšak se zachováním výstupů. Jelikož však nemá RBF žádná pravidla vyžadující, aby měla nahrazující transakce vyšší „těžební skóre” (tj. byla by rychleji vybrána do bloku), mohl by útočník „přišpendlit” tento druh transakcí vytvořením nahrazení zatíženého předky s nízkými jednotkovými poplatky. Existující limity předků a potomků nejsou dostatečné, aby omezily výpočetní náročnost této kalkulace, což ztěžuje přesný odhad těžebního skóre transakcí a balíčků transakcí. Jakékoliv připojené transakce mohou ovlivnit pořadí, ve kterém jsou transakce vybírány do bloku. Komponenta, která je plně propojena (nazývající se cluster), může mít jakoukoliv velikost danou současnými limity předků a potomků.

Dlouhodobým řešením adresování některých nedostatků mempoolu a RBF pinning útoků je v mempoolu předělat strukturu dat, aby se sledovaly clustery namísto pouhých množin předků a potomků. Tyto clustery by byly omezeny ve velikosti. Limity clusterů by omezily způsob, kterým by mohli uživatelé utrácet nepotvrzená UTXO, ale díky nim by mohl být celý mempool linearizován použitím těžebního algoritmu založeném na skóre předků, tvorba šablon bloků by byla extrémně rychlá a mohl by být přidán požadavek, aby nahrazující transakce měly vyšší těžební skóre než transakce, které chtějí nahradit.

I přesto je možné, že žádná jedna sada pravidel nemůže uspokojit širokou řadu potřeb a očekávání přeposílání transakcí. Například zatímco pro příjemce dávkové platby je výhodné, že mohou utratit své nepotvrzené výstupy, uvolněné limity potomků vytváří prostor pro pinning RBF balíčků sdílené transakce skrz absolutní poplatky. Návrh na pravidla přeposílání v3 transakcí byl vyvinut, aby umožnil protokolům s kontrakty volitelně používat striktnější sadu limitů balíčků. V3 transakce by povolovaly pouze balíčky o velikosti dva (jeden předek, jeden potomek) a omezovaly váhu potomka. Tyto limity by zabraňovaly RBF pinningu skrz absolutní poplatky a nabídly by některé z výhod mempoolu clusterů bez nutnosti restrukturovat mempool.

Ephemeral anchors dále vylepšují anchor výstupy na základě vlastností přeposílání v3 transakcí a balíčků. Anchor výstupy patřící v3 transakci s nulovým poplatkem budou mít výjimku z limitu neutratitelnosti („dust limit”), pokud jsou utráceny potomkem navyšujícím poplatek. Jelikož transakce s nulovým poplatkem musí mít poplatek navýšený právě jedním potomkem (jinak by neměl těžař motivaci ji začlenit do bloku), je tento anchor výstup dočasný („ephemeral”) a nestane se součástí množiny UTXO. Tento návrh na ephemeral anchors implicitně zabraňuje neanchor výstupům, aby byly utraceny, dokud jsou nepotvrzené a nemají 1 OP_CSV časové zámky, neboť potomek musí tento anchor výstup utratit. Díky tomu by také byl proveditelný LN symmetry (eltoo), který by mohl využít CPFP jako mechanismu poskytování poplatků transakcím uzavírajícím kanál. Dále by mohl být tento mechanismus použit u transakcí sdílených mezi více než dvěma účastníky. Vývojáři používají k nasazení ephemeral anchors a navrhovaných soft forků bitcoin-inquisition, v jehož rámci budují a testují tyto změny na signetu.

Problém pinningu, popsaný mimo jiné v tomto příspěvku, stál loni za množstvím diskuzí a návrhů vylepšení pravidel RBF v emailových skupinách, pull requestech, sociálních médiích a při osobních setkáních. Vývojáři navrhli a implementovali řešení v různých škálách, od malých úprav až po kompletní předělání. Volba -mempoolfullrbf, jejímž účelem je potýkat se s problémem pinningu a nesouladem v BIP125 implementacích, nám připomenula náročnost a důležitost spolupráce v rámci pravidel přeposílání transakcí. A i když byly upřímné snahy o zapojení komunity použitím obvyklých prostředků včetně konverzace v emailové skupině Bitcoin-Dev rok dopředu, bylo zřejmé, že existující způsoby komunikace a rozhodování nevyústily v zamýšlený výsledek a potřebovaly doladit.

Decentralizované rozhodování je náročným, ale nezbytným procesem v podpoře různorodého ekosystému protokolů a aplikací, které používají bitcoinovou síť. Příští týden bude náš poslední příspěvek v této sérii, ve kterém, doufáme, se nám podaří zapojit čtenáře a zlepšit tento proces.

Zapojte se

Původně vyšlo ve zpravodaji č. 260

Doufáme, že tato série poskytla čtenářům lepší porozumění, co se děje během čekání na potvrzení. Začali jsme zkoumáním, jak se ideologické hodnoty bitcoinu projevují v jeho struktuře a designu. Distribuovaná struktura peer-to-peer sítě nabízí oproti běžnému centralizovanému modelu zvýšené soukromí a odolnost vůči cenzuře. Otevřená síť propagace transakcí umožňuje každému dozvědět se o transakcích ještě před jejich potvrzením, což zlepšuje efektivitu propagace bloků, usnadňuje počátky novým těžařům a přináší veřejnou aukci blokového prostoru. Jelikož ideální síť sestává z mnoha nezávislých anonymních entit provozujících uzly, musí být software uzlů navržen tak, aby ochraňoval před DoS a minimalizoval provozní náklady.

Poplatky hrají v bitcoinu důležitou úlohu jako „spravedlivý” způsob řešení soutěže o blokový prostor. Mempooly s nahrazováním transakcí a algoritmy výběru a vyloučení využívají k měření užitku transakcí ekonomické incentivy a dávají uživatelům k dispozici nástroje k navyšování poplatků: RBF a CPFP. Kombinace pravidel mempoolu, peněženek se schopností ekonomické konstrukce transakcí a dobrý odhad poplatků vytváří efektivní trh blokového prostoru, který přináší užitek všem.

Jednotlivé uzly dále vynucují pravidla přeposílání transakcí, aby chránily samy sebe před vyčerpáním zdrojů a vyjadřovaly své osobní preference. Na úrovni celé sítě jsou aplikována pravidla standardnosti pro ochranu zdrojů nutných pro škálování, dostupnost uzlů a schopnost měnit pravidla konsenzu. Jelikož drtivá většina sítě tato pravidla vynucuje, jsou důležitou součástí rozhraní, nad nímž jsou bitcoinové aplikace a protokoly druhé vrstvy vystavěny. Avšak nejsou dokonalá. Popsali jsme několik návrhů kolem pravidel, které adresují obecná omezení i konkrétní případy jako jsou například pinning útoky transakcí na druhé vrstvě.

Též jsme zdůraznili, že probíhající evoluce pravidel sítě vyžaduje spolupráci mezi vývojáři pracujícími na protokolech, aplikacích i peněženkách. S růstem bitcoinového ekosystému, tedy s množstvím software, případů užití a uživatelů, roste důležitost i náročnost procesu decentralizovaného rozhodování. Tento systém vyvstává ze zájmů a cílů účastníků bitcoinové sítě. Není v jejím středu žádná firma sbírající názory zákazníků a najímající inženýry k přidávání nových funkcí. Kdo si přeje být součástí širšího konsenzu sítě, může si vybrat svou cestu: může se učit, ptát se, hlásit problémy, účastnit se návrhu sítě nebo přímo přispívat ve vývoji novinek.

Až budete příště příliš dlouho čekat na potvrzení své transakce, budete vědět, co dělat.