Ak čítate tento článok tesne po vydaní, pravdepodobne ešte stále vidíte kopu tweetov, Nostr postov či iných komentárov na tému OP_RETURN. Asi ste už počuli, že to súvisí s ukladaním dát to Bitcoin time chainu (po starom block chain), ale o čo v skutočnosti ide? Téma je celkom komplikovaná a pre úplné pochopenie treba chápať niekoľko konceptov, ktoré tu vystvetlím spolu s analýzou situácie.
Keďže Bitcoin má byť vzácny (21M limit), a je zároveň elektronický, je nutné zabezpečiť aby tie isté satoshi neboli minuté dva krát (tým istým vlastníkom). V decentralizovanej sieti je jedinou možnosťou ako to dosiahnuť zverejnenie "účtovnej knihy". Každý účastník musí vedieť o každej transakcii. Dôsledkom je, že Bitcoin je jedna z najviac replikovaných databáz, tzn kópia dát Bitcoinu je na obrovskom počte počítačov po celom svete. Vďaka tomu je Bitcoin veľmi odolný aj voči obrovským živelným katastrofám a nehodám.
Táto vlastnosť je ale zaujímavá aj pre ľudí mimo Bitcoin alebo pre bitcoinerov na účely iné ako samotné transakcie. A preto už tesne po vzniku Bitcoinu doňho začali ľudia ukladať informácie navyše. (Zlé jazyky hovoria, že Satoshiho správa v Genesis bloku bola len politický komentár - nebola, bol to aj dôkaz, že Satoshi nezačal ťažiť skôr.) Už vtedy sa ohľadom témy viedli diskusie a sentiment bol nepoužívať Bitcoin na nefinančné účely. Avšak tomu je náročné zabrániť v decentralizovanom systéme dizajnovanom na obranu voči cenzúre.
Ďalšou vlastnosťou uloženia informácií do Bitcoin time chain je schopnosť dokázať, že informácie boli známe v konkrétnom časovom rozsahu. (Čas bloku nie je presný, treba počítať s možnou odchýlkou 2 hodiny a tiež s dobou potvrdenia.) Niektorí ľudia si myslia, že priamo uloženie informácie je nutné, avšak v skutočnosti to tak nie je. Je možné vytvoriť dôkaz o znalosti informácie a "primiešať" ho do verejného kľúča tak, že sa nezmení jeho veľkosť a dokonca pre tretiu stranu ani nie je možné určiť, či sa v kľúči taký dôkaz nachádza alebo nie. V angličtine sa to volá "commitment" a dalo by sa to preložiť ako "kryptografický záväzok".
Funguje to podobne ako zapečatená obálka. Obsah obálky zostáva skrytý a nemenný, kým ju niekto neotvorí. Rovnako informácie "zapečatené" v kľúči sú skryté a nemenné. No treba zdôrazniť, že tam nie sú reálne uložené - dá sa k nim dostať iba tak, že ich autor prezradí a potom sa len overí, či ich autor nezmenil. Je to podobné ako keď rozpustíme kryštál soli vo vode - dá sa zistiť, že je slaná, ale pôvodný kryštál z nej nedostaneme.
Takýto kľúč zmiešaný s dôkazom aj funguje ako normálny verejný kľúč. Na vloženie do time chainu stačí urobiť úplne obyčajnú transakciu na adresu zodpovedajúcu tomu kľúču a dôkaz je hotový. Je to veľmi efektívne. Túto techniku používa priamo aj Bitcoinové vylepšenie Taproot a pre nefinančné účely služba Open Timestamps poskytuje zdarma nástroje na vytváranie takýchto dôkazov. A keďže sa pritom nemení veľkosť dát, nemusíme to ďalej rozoberať v tejto téme.
Existuje však ešte jedno špecifické využitie ukladania informácií. V niektorých kryptografických protokoloch, ako napr Lightning Network, je nutné zabezpečiť, aby bola za istých (núdzových) okolností zverejnená konkrétna informácia. Nestačí len dôkaz, že v nejakom čase existovala; relevantní účastníci protokolu musia mať k nej prístup. Zároveň je potrebný aj dôkaz, že informácia je skutočne dostupná - nestačí ju len "uložiť do cloudu", či azda zverejniť v novinách. Bitcoin timechain tu ponúka prirodzené riešenie: každý používateľ Bitcoinu s full nodom má prístup ku všetkým dátam v time chaine a zároveň, ak by k zverejneniu nedošlo, určitá transakcia by nebola považovaná za platnú. Čiže je možné zabezpečiť, že buď všetko prejde v poriadku alebo sa nič nestane (t.j. nič sa nepokazí).
Pre úplnosť si zopakujme typy nodov, pretože ľudia v nich majú niekedy zmätok.
Pojem "full node" znamená akýkoľvek node, ktorý urobil kompletné overenie time chainu. To znamená, že ak by dostal blok, ktorý by porušoval akékoľvek pravidlo, tak by ho odmietol. Rovnako ako validátor bankoviek odmietne falošnú bankovku. Je to veľmi dôležité na zabránenie podvodom.
Niektorí ľudia si myslia, že pruned node nie je full node, ale nie je to pravda. Pruned node je jednoducho taký full node, ktorý sa zbaví starých a nepotrebných dát. To znamená staré bloky. Overovať môže naďalej v plnej miere, pretože má stále potrebné dáta a tie nezahodí, pokiaľ ich treba. Pruned node teda dokáže všetko to, čo iný full node (tzv full archival node), avšak v prípade získavania starých blokov sa zvyšuje odozva a zaťaženie siete používateľa.
Samozrejme, keby celá sieť používala iba pruned nody, mali by sme problém, lebo staré bloky by sa stratili, ale v praxi nevyzerá že by to hrozilo. Cena úložiska, čo uchová toľko dát je do 50 EUR a to tiež počítam s rýchlym SSD, pomalé HDD (čo môže stačiť) je ešte lacnejšie.
Naproti tomu SPV node je taký, ktorý sa spolieha iba na čiastočné overenie. Neoveruje všetky pravidlá, pretože porušiť niektoré je pre minerov extrémne drahé, pokiaľ je v sieti dosť ekonomicky aktívnych full nodov. To znamená full nodov, ktorých majitelia bežne prijímajú bitcoiny (v dostatočne veľkých sumách). Ak by full nodov bolo málo, šanca úspechu útoku narastá a tým aj riziko pre SPV nody. Výhodou SPV nodu je, že spotrebuje menej výpočtového výkonu, miesta na disku a sieťovej kapacity. Preto ich používajú ľudia, ktorí si full node nemôžu dovoliť alebo v situáciách, kedy je nepraktické ho použiť (napr. na telefónoch).
Full nody sú teda kľúčové pre fungovanie Bitcoinu a množstvo ľudí je právom proti zmenám, ktoré by príliš zvyšovali cenu ich prevádzky.
Pre istotu ešte zopakujme čo sú to forky: sú to akékoľvek zmeny v pravidlách Bitcoinu. Umožňujú Bitcoin vylepšiť alebo opraviť kritické chyby. No ich realizácia je veľmi náročná, pretože vyžadujú, aby obrovské množstvo ľudí aktualizovalo svoj node. Poznáme dva typy: soft forky a hard forky. Soft forky sprísňujú pravidlá a ich realizácia je oveľa ľahšia ako realizácia hard forkov, ktoré pravidlá uvoľňujú. Bitcoin mal historicky iba jeden hard fork (niektorí by argumentovali, že to ani hard fork nebol) a niekoľko soft forkov.
Snáď každý, kto počul o Bitcoine vie, že používa "akýsi blockchain", no už málokto vie o verejnej (P2P - skratka z "peer to peer") sieti, ktorá je tiež veľmi významná. Umožňuje spoľahlivo šíriť dôležité informácie medzi nodami. A nie, nie je to "blockchain" ani "timechain". Touto sieťou si nody posielajú najmä transakcie a bloky. Každý node je pripojený k niekoľkým iným nodom, ktorým môže informácie posielať. Tie potom posielajú ďalej a tie ďalej. Ako hra na telefón.
Takto sa časom každá transakcia a každý blok dostane ku každému, vrátane minerov. No v princípe táto sieť nie je nevyhnutná na niektoré základné operácie. Je možné napr. spojiť sa s minerom priamo a posielať mu transakcie. No obchádzanie verejnej siete nie je dobré pre odolnosť Bitcoinu (na to sa pozrieme v neskoršej časti).
Bitcoin má dve sady pravidiel transakcií: konsenzus pravidlá a pravidlá štandardnosti. Konsenzus pravidlá sú "tvrdé" - hovoria o tom, aké bloky sú akceptovateľné pre účastníkov siete a miner, ktorý by ich porušil by nedostal zaplatené za vyťaženie bloku. Pravidlá štandardnosti sú "mäkké" - hovoria o tom, aké transakcie sú nody ochotné šíriť ďalej verejnou sieťou, predpokladajúc, že časom dorazia k minerovi. Avšak je možné ich porušiť napríklad tým, že niekto priamo kontaktuje minera a pošle mu transakciu.
Zmena konsenzus pravidiel teda nutne znamená fork. Zmena pravidiel štandardnosti ovplyvňuje iba to, aké transakcie sa budú šíriť verejnou Bitcoin sieťou. Ak by mali rôzne nody rôzne pravidlá konsenzu, mohla by sa sieť rozdeliť na časti, čo je dosť katastrofálna udalosť. (Ktorá sa raz bohužiaľ stala a SlushPool - súčasný Braiins vtedy prišiel o dosť peňazí.) Ak by mali rôzne nody rôzne pravidlá štandardnosti, tak to nie je katastrofa, normálne Bitcoin funguje ďalej, len niektoré nody a niektorí mineri môžu mať problémy.
A veruže, v praxi sa pravidlá štandardnosti rôznia. Okrem najpopulárnejšej implementácie full nodu, Bitcoin Core, existujú ďalšie alternatívne. Napríklad známe sú Bitcoin Knots a Libre Relay. Bitcoin Knots má striktnejšie pravidlá štandardnosti, Libre Relay ich má naopak uvoľnenejšie. Výsledok je, že tie striknejšie nemajú praktický efekt na bloky - ak niekto chce zverejniť transakciu, ktorá ich porušuje, stačí si nainštalovať Libre Relay a použiť. A dokonca je možné porušiť úplne hocijaké pravidlá štandardnosti.
Aj keď sa dajú pravidlá štandardnosti rôznymi spôsobmi obísť a nebránia v samotnom vyťažení transakcie, neznamená to, že sú zbytočné. Naopak, zohrávajú dôležitú úlohu. Pomáhajú chrániť sieť pred niektorými DoS útokmi (snahy o preťaženie nodu), uľahčujú zavádzanie rôznych vylepšení Bitcoinu a znižujú riziko, že používatelia omylom vytvoria problematické alebo nezvyčajné transakcie. Vďaka nim môžu soft forky bezpečne obmedziť určité typy transakcií bez toho, aby ohrozili existujúcich používateľov. Pravidlá tak slúžia ako filter pre transakcie, ktoré by mohli byť škodlivé, neefektívne alebo v praxi nemajú legitímne využitie – napríklad také, ktoré by viedli k strate BTC alebo zbytočne zaťažili uzly v sieti. No ak niekto naozaj chce vytvoriť transakciu mimo týchto pravidiel, stále má tú možnosť.
i
Ako to funguje:
Každý node je pripojený k niekoľkým iným nodom a keď chce odoslať transakciu do siete, pošle ju každému z pripojených nodov. Každý potom overí, či transakcia je platná podľa pravidiel konsenzu a či spĺňa štandardnosť z pohľadu toho konkrétneho node. Ak nie, transakciu proste zahodí (a prípadne zablokuje odosielajúci node, aby sa ušetrili zdroje). Ak áno, transakciu odošle ostatným nodom, na ktoré je pripojený. Tým sa transakcia exponenciálne šíri sieťou.
Rovnako sa šíri aj blok, avšak blok nemá pravidlá štandardnosti (akékoľvek obmedzenie blokov je pravidlo konsenzu). Čiže všetky nody šíria blok rovnako a akceptujú ho aj keď niektorá z transakcií v ňom nespĺňa pravidlá štandardnosti (akékoľvek). No a k tomu je tam optimalizácia, že ak už má node nejaké transakcie z bloku (ideálne vštky), netreba ich posielať znovu. Stačí poslať hashe transakcií a coinbase a na základe nich si node vypýta chýbajúce.
Ak rôzne nody majú rôzne pravidlá, tak stačí, že transakcia prejde niekoľkými, nemusí prejsť každým. Časom sa k minerom dostane. A pre minera je výhodné pravidlá štandardnosti prevažne ignorovať, pretože získa viac satoshi z poplatkov. Preto v sieti vyhrávajú nody s najmenej prísnymi pravidlami. Ak majú mineri s dostatkom hash rate laxnú implementáciu a zároveň ju používa odosielajúci, dokážu sa takéto nody nájsť a prepojiť (to robí napr aj Libre Relay - fork Bitcoin Core), takže transakcie sa k minerom dostanú.
Pravidlá štandardnosti však majú aj svoje temné stránky. Jednou z nich je to, že kvôli rôznym pravidlám sú mempooly rôzne, takže sa ťažšie zisťuje aké sú skutočné poplatky v sieti. To môže mať za následok aj nespoľahlivosť uzatvárania LN kanálov a v extrémnom, veľmi hypotetickom prípade, stratu satoshi kvôli podvádzaniu. Ďalším problémom je, že ak existuje túžba niektoré pravidlá obísť a nedá sa nájsť alternatíva pomocou verejnej siete, je nutné kontaktovať priamo minerov. Lenže nikto sa nebude obťažovať kontaktovať nejakého solo minera, ktorý má 0.01% výkonu siete aby mu zaplatil za to, že s pravdepodobnosťou 0.01% vyťaží jeho špeciálnu transakciu. Ten, kto chce ťažiť špeciálne transakcie, jednoducho kontaktuje zopár veľkých poolov, zaplatí im, možno aj pomimo time chain, a transakcia sa vyťaží.
To ale dáva konkurenčnú výhodu veľkým minerom, lebo majú extra príjem, ktorý malí nemajú - priamo v protiklade s myšlienkou decentralizácie. Zároveň, bloky, ktoré majú špeciálne transakcie, sa šíria pomalšie sieťou, lebo nemôžu tak dobre využiť optimalizáciu opísanú vyššie. Za normálnych okolností sa na šírenie blokov používa optimalizácia, ktorá využíva prítomnosť transakcie v mempoole nodu, aby ju nebolo treba posielať znovu. Lenže špeciálne transakcie v mempoole nie sú a musia sa teda poslať.
Nanešťastie, pomalé šírenie bloku dáva zase konkurenčnú výhodu veľkým minerom. Akonáhle je vyťažený nový blok, mineri, ktorí o ňom ešte nevedia, stále ťažia na starom. A s pravdepodobnosťou, ktorá je proporcionálna ich výkonu, sa stane, že nájdu alternatívny blo blokk, ktorý bude súperiť s tým, ktorý našiel iný miner. Ak však blok nenájdu, sú to iba spálené peniaze, lebo ťaženie nemalo zmysel. V prípade malých minerov sa štatisticky častejšie stane, že alternatívny blok nenájdu a budú mať vyššie straty. Veľkí mineri naopak získavajú tým, že sa zbavujú konkurencie.
Výsledok je, že malí mineri skôr zbankrotujú a sieť ostane iba väčším minerom, či poolom, podkopávajúc decentralizáciu.
Aby toho nebolo málo, rôznosť pravidiel zároveň môže spôsobiť väčšiu záťaž nodov. Vždy, keď node šíri transakciu verejnou sieťou, musí spotrebovať nejaké zdroje, aby ju spracoval. Aby nebolo možné node jednoducho zaspamovať, vyžaduje aby transakcia bola platná a platila dostatočne vysoký poplatok. Pokiaľ sú pravidlá rôzne, je však možné poslať rôzne transakcie rôznym nodom, no po vyťažení bude platná len jedna z nich. To za určitých okolností môže viesť k tomu, že nody zbytočne spotrebujú zdroje na spracovanie transakcie, čo má za následok, že prevádzka takýchto nodov je náročnejšia a bude ich menej.
Pravdu povediac, trochu vyššia záťaž nodov v praxi nie je nejako veľký problém a útok je drahý. Aj keby pár nodov vyplo službu preposielania transakcií, stále sa ich nájde dosť, ktoré to budú robiť a netreba ich aspoň zatiaľ veľké množstvo. Je to však celkom zaujímavý detail a ktovie ako sa potreba týchto nodov vyvinie v budúcnosti.
Naprotiveň fanúšikom Etherea, Bitcoin podporuje smart kontrakty a podporoval ich od samého začiatku, už keď ho vydal Satoshi. Aby to bolo možné, nerozhoduje o umožnení transferu Bitcoinu priamo podpis, ale krátky program (nazvaný Bitcoin Script), ktorý môže obsahovať verifikáciu podpisov. Tento program sa skladá z inštrukcií a jedna z nich sa nazýva OP_RETURN. Táto inštrukcia hovorí, že transfer je neplatný a hneď transakciu odmietne bez ďalšieho pokračovania v scripte. A práve táto inštrukcia sa stala základným blokom pre vyriešenie vážneho problému s ukladaním dát.
i
Táto inštrukcia kedysi fungovala trochu inak - umožnila script aj označiť ako okamžite platný. Malo to však jeden vážny problém: dalo sa to urobiť aj vo vstupnom scripte. Čiže každý mohol minúť bitcoiny každého!
Ak nemáte veľa miesta na disku ale chcete bežať full node, v súčasnosti to nie je problém. Proste zapnente "pruning" - priebežné mazanie starých a nepotrebných údajov. Avšak, niektoré dáta sú protrebné a to najmä UTXO set - množina všetkých neminutých "mincí" - výstupov. Tá narastá s každým výstupom transakcie. No ale práve do tých výstupov ľudia v minulosti ukladali dáta, maskujúc sa ako verejné kľúče, pretože iné alternatívy neboli praktické. Tým nemyslím "commitment", ako bol opísaný vyššie, ale fiktívny verejný kľúč ku ktorému nikto (ani sám autor) nepozná súkromný.
Vtedy boli štandardné iba transakcie obsahujúce výstupy typov P2PK, P2PKH, P2SH. Kto chcel ukladať dáta, poslal proste pár satoshi "na adresu" avšak v skutočnosti táto "adresa" boli zakódované údaje. A keďže súkromný kľúč nie je známy, nikdy nebude možné výstup minúť. Následok je, že už nikdy nijaký majiteľ full nodu nebude môcť tieto údaje zmazať, lebo nevie, že sa minúť nedajú. Ani keby s tým súhlasil ten, kto tam tie údaje pridal, lebo sa nedá dokázať, že to tak urobil a že je vôbec právoplatným majiteľom, lebo nemá privátny kľúč.
Ďalší problém takéhoto ukladania dát je, že spotrebúva aj dáta navyše. Každý výstup potrebuje minimálne 9B v transakcii navyše. No, štandardné výstupy potrebujú aspoň 11B. A ak je výstupov veľa, tak sa veľkosť navýši ešte o kúsok, ale pre jednoduchosť to teraz ignorujme (pointa platí aj bez toho). Ak by teda niekto chcel uložiť napr 320B dát, musel by ich rozdeliť na 10 častí. To by vo výsledku znamenalo zabratie 430B dát. No a pre každý taký výstup v UTXO set treba 92B dát, čo znamená, pre takú transakciu sa ukladá 920B dát v UTXO set a teda dokopy transakcia zaberá na full archival node 1240B dát - skoro štvornásobok toho, čo chcel niekto uložiť.
A nielenže tieto dáta zaberajú miesto, ale spomaľujú aj verifikáciu time chainu. Tento fenomén je výborne popísaný v technických článkoch The Myth of RAM. Nebudem to tu rozoberať, lebo je to náročné, ale faktom je, že čím väčšie úložisko, tým dlhšie trvá z neho vyťahovať dáta v náhodnom poradí (prípad Bitcoinu).
i
Existuje trik na urýchlenie synchronizácie Bitcoinu, ktorý ale vyžaduje dostatok RAM. Keď nastavíme veľkosť cache pre UTXO set na väčšiu ako veľkosť UTXO set, node nepotrebuje robiť pomalé prístupy na disk počas verifikácie. Ešte pred pár rokmi bola veľkosť UTXO set okolo 4GB. Taká RAM bola dosť rozšírená a lacná. No dnes má už okolo 12GB, takže ak niekto chce tento trik využiť, musí si kúpiť väčšiu RAM. Je to ďalší dôvod, prečo je zväčšovanie UTXO set problém.
Keď sa takéto ukladanie stalo populárnym, predstavovalo to pre Bitcoin problém. Ako riešenie vývojári Bitcoin Core zmenili štandardnosť tak, že umožnili aby scripty vo výstupoch začínali inštrukciou OP_RETURN a výstup, ktorý takýto script obsahuje môže mať nulovú sumu. (Tá bola tiež neštandardná.) Takýto script teda vždy zakáže minúť dotyčné bitcoiny (predošlý výstup). Táto vlastnosť je, na rozdiel od verejných kľúčov, priamo viditeľná v scripte pre každý node. No a keďže výstup sa dokázateľne nedá minúť, netreba ho ukladať do UTXO set, lebo ho určite nebude nikto potrebovať. Ušetrí sa teda teoreticky zhruba 75% dát pre full archival node a 100% pre pruned node. Navyše nulový limit na sumu predstavuje drobnú zľavu za to, že sa používa efektívnejšia metóda ukladania a motivuje ľudí preferovať túto šetrnejšiu metódu.
No aj takýto výstup so scriptom začínajúcim s OP_RETURN bol so štandardným limitom 80B (pôvodne 40B, v priebehu histórie sa menil). To donedávna stačilo na väčšinu použití, pretože sa prevažne používal na ukladanie hashov menej efektívnych timestamp služieb alebo verejných častí stealth address protokolu. No vyskytol sa nový protokol, ktorý potrebuje 144B. Ten opäť zvyšné dáta ukladá do ďalších výstupov, nafukujúc UTXO set. Bolo by možné limit proste zvýšiť, ale ak by sa neskôr zase niečo podobné vyskytlo, diskusia by sa zopakovala a stále by platilo, že ak sa limit nezvýši, bude niekto ukladať do UTXO set. Takže je jednoduchšie proste limit odstrániť. (Limit bloku 4MB ostáva, takže dá sa povedať, že ten limit 80B sa zvýšil na necelých 4MB) A práve o tom je aktuálna diskusia.
Spracúvanie a ukladanie dát o transakciách všetkých ľudí je prirodzene náročné na procesorový výkon a iné zdroje. Keď do to toho pridáme nefinančné dáta, je to ešte náročnejšie. To na jednej strane obmedzuje koľko transakcií sieť môže spracovať a na druhej udáva minimálne hardwarové požiadavky pre full node. Riziko zahltenia siete viedlo k jednému z najznámejších parametrov Bitcoinu - 4MB limit veľkosti bloku.
Detaily sme dopodrobna rozoberali v podcaste s Duškym. Skrátená verzia je, že veľké bloky vytvárajú tlak proti decentralizácii. Ak je cena overenia time chainu kvôli množstvu dát príliš vysoká, málo ľudí bude overovať všetky dáta v sieti a hrozí riziko, že dôjde k porušeniu pravidiel, napríklad aj infláciou. Ak je veľkosť bloku príliš nízka, poplatky za použitie time chainu stúpajú a tlačia ľudí používať custodial služby, ktoré by ich mohli okradnúť alebo špehovať. Kvôli tomu v roku 2017 Bitcoineri viedli virtuálnu vojnu, lebo bolo náročné dohodnúť sa ako vyriešiť tieto výzvy. Napokon vyhralo zvýšenie limitu z 1MB na 4MB a podpora technológií ako je Lightning Network. (Niektorí zmätení ľudia aj teraz, takmer 8 rokov od konca "vojny", tvrdia, že veľkosť je 1MB)
Samozrejme, aj keď máme limit na veľkosť bloku, stále je lepšie aby boli bloky menšie, ak je to možné. Extra dáta stále veľkosť bloku zvyšujú. Snáď nijaký developer netúži aby boli bloky väčšie. V ideálnom svete by veru mali nekonečnú zápornú veľkosť! To sa samozrejme nedá, tak sa musíme uspokojiť s nejakou kladnou veľkosťou. Logicky by dávalo zmysel blokovať extra dáta, to však ale nie je možné a alternatívy sú horšie.
Dokonca kupodivu extra dáta sa spracúvajú oveľa ľahšie ako obyčajné transakcie. Je to kvôli tomu, že Bitcoin Core obsah tých dát nepotrebuje overovať - stačí ich zahashovať aby sa uistil, že sa nezmenili. Naproti tomu, transakčné dáta obsahujú podpisy a ich overenie je veľmi výpočtovo náročné v porovnaní s hashovaním (ono aj to hashovanie vrámci nich prebieha). To vedie k paradoxu: síce ak blok nie je plný, tak pridávanie extra dát znižuje rýchlosť overovania, no ak je blok plný, tak extra dáta vytláčajú kľúče, podpisy a pod, ktorých spracovanie by trvalo dlhšie, čiže rýchlosť spracovania sa zvýši! Pre rýchlosť validácie je lepšie mať 1MB blok iba s finančnými dátami ako mať 3MB blok s finančnými dátami a s extra nefinančnými dátami navyše, ale je tiež lepšie mať 4MB blok s nefinančnými dátami ako mať 4MB blok s finančnými dátami.
Keďže príliš veľké množstvo dát v time chaine je problém, niektorí ľudia by radi extra dáta zablokovali. Pozrime sa ako by to vyzeralo.
V súčasnosti sa používajú tri hlavné spôsoby ukladania dát:
Prvé dva som už vysvetlil, ten posledný ukladá dáta do podpisu transakcií a používajú ho inscriptions. Keďže sa dá ľahko vymazať má aj zľavu 75%. (Ako som ukázal vyššie, zhruba toľko sa ušetrí, no dá sa argumentovať, že kvôli pruningu by tá zľava mala byť vyššia.) Predstavme si, že by sme chceli všetky spôsoby zablokovať. Najskôr iba štandardnosťou: Zablokovať výstup, ktorého script začína OP_RETURN je ľahký, proste by sme odstránili výnimku z kódu, ktorá tam bola pred rokmi pridaná a máme hotové.
Witness dáta sú podstatne ťažšie - aby sme neohrozili legitímne položky vo Witness, museli by sme nejako sledovať, ktoré inštrukcie nespotrebúvajú dáta. Napríklad by mohlo byť nutné zakázať inštrukciu OP_DROP, ak prvok, ktorý odstraňuje nebol predtým použitý v niektorej z legitímnych inštrukcií. No museli by sme sa zbaviť aj rôznych trikov, kde sa kombinujú inštrukcie aby to obišli. (Napr OP_DUP OP_EQUALVERIFY) Ak tomu nerozumiete, je to v podstate pointa: je to ťažké. Ale myslím si, že by to šlo. (Pre ITčkárov: Script nie je turing-kompletný.) Bolo by to samozrejme extra procesovanie dát naviac.
Neminuteľné kľúče majú primočiare riešenie: mohli by sme vyžadovať, aby tí, čo sa snažia transakciu odoslať dokázali, že kľúče sú funkčné. To je vlastne celkom ľahké, stačí aby podpísali nejakú konkrétnu správu (nie transakciu). Prvý problém je, že verifikácia podpisov je dosť náročná operácia a viedla by k záťaži nodov. Druhý je, že by sme to museli urobiť aj pre Taproot - vylepšenie, ktoré sa aktivovalo pred pár rokmi a prináša významné optimalizácie v time chaine a dokonca zlepšenie súkromia. Vyžadovaním podpisov by sa však pokazili niektoré možnosti použitia. (Napríklad súčasná implementácia Firefish by prestala fungovať.) A výrazne by to podkopalo výhody súkromia, ktoré Taproot priniesol.
Toto všetko by však stále nezabránilo ľuďom kontaktovať minerov, a ako som písal vyššie, viedlo by to k centralizácii. No ak by sme to chceli ako soft fork, bolo by to ešte horšie. V prvom rade, by bolo náročné extra dáta o dôkazoch overovať v rámci konsenzu, takže by to muselo ísť "pomimo", podobne ako vylepšenie SegWit prenáša podpisy "pomimo". Ten kód je dosť komplikovaný a bolo by ho náročné napísať aj dlhodobo udržiavať. Ďalšie dáta by priniesli aj extra náklady na overovanie, ktoré by však teraz už boli povinné a pre všetky transakcie od určitého bloku. Čiže ironicky by sa záťaž nodov a cena synchronizácie ešte viac zvýšila. A nie triviálne - môj dávny experiment ukázal, že overovanie podpisov všetkých transakcií a neoverovanie urobí rozdiel v synchronizácii rádovo v dňoch! Spolu s nutnosťou odhaliť dáta z Taprootu by sme navyše stratili úplne všetky jeho výhody - aj optimalizáciu veľkosti, aj súkromia, aj výkonu.
No nie je to všetko! Ak by sme aj zablokovali všetky tieto spôsoby ukladania dát, čo vôbec nie je ľahké, ostal by jeden, ktorý nikdy nebude možné blokovať: steganografia - skrývanie toho, že sa niečo skrýva. Už veľmi dávno som napísal program, ktorý demonštroval, že je možné vygenerovať postupnosť Bitcoin adries, do ktorých je ukrytá tajná informácia. Sú to plnohodnotné adresy - normálne sa na ne dá prijať, aj odoslať z nich. Každá má svoj privátny kľúč a je možné to dokázať iným nodom - čiže prešli by kontrolou opísanou vyššie. A keďže dáta sú zašifrované, nie je možné odlíšiť ich od legitímnej postupnosti adries. Inými slovami, nikdy nebude možné urobiť na ne filter. Nevýhoda tohto riešenia je, že zaberá násobne viac dát a vytvára násobne viac výstupov. Navyše, ak sa adresy skutočne použijú na minutie, vyžaduje ešte viac času na overenie kvôli podpisom, ako som písal vyššie. (No aspoň nespôsobia dlhodobý problém zvzväčšenia UTXO set.)
Výsledok je, že time chain by sa zväčšil už aj sám o sebe, a k tomu dostatočne motivovaní "ukladači dát" by boli donútení zväčšiť time chain ešte viac. Samozrejme, zaplatili by za to viac satoshi ako dnes ale určite by ich to odradilo? Ak dnes ľudia platia milióny za obrázok opice, či banánu nalepeného na stene, tak pochybujem, že pár desiatok eur, či nebodaj stoviek navyše by ich odradilo.
Celá vec je dvojnásobne ironická: nastalo by presne to, čomu sa blokovanie snažilo zabrániť a k tomu by šlo v podstate o snahu cenzúrovať - pritom Bitcoin bol vyslovene dizajnovaný aby cenzúra bola prakticky nemožná. No, ono tá nemožnosť blokovať "nefinančné transakcie" bude asi dôsledkom obrany pred cenzúrov.
Čiže, ako hovoria naši českí bratia, "tudy cesta nevede".
Nedávno na základe týchto argumentov (v kratšej forme) vývojári Bitcoinu navrhli odstránenie 80B limitu štandardnosti pre výstupy, ktorých script začína OP_RETURN. Táto téma bola diskutovaná vo verejnom mailing liste. Ktokoľvek si mohol prečítať argumenty a reagovať. Keďže však vývojári rozumeli, že limit je skôr škodlivý, v diskusii súhlasili a jeden z nich pripravil zmenu kódu, ktorú odoslal ako pull request. (Pull request slúži na technické pripomienkovanie, či kód funguje správne.)
Po "vojne o Bitcoin" mnohí bitcoineri zostali obozretní, možno až ustráchaní ohľadom zmien Bitcoinu. V istom zmysle je veľmi dobré, že sú ľudia skeptickí voči zmenám a pustia sa do boja. Kiežby to tak ostalo. Bohužiaľ v tomto prípade mnohí vôbec nečítali argumenty na mailing liste a hneď zbrklo reagovali na GitHube pull requeste. Avšak, GitHub pull request nie je vhodné miesto na takúto diskusiu.
Preto moderátor, technicky správne, skryl irelevantné príspevky, ale tým asi ešte viac naštval dotyčných. Samozrejme, vyzerá to ako cenzúra. V kombinácii s podozrivo vyzerajúcou zmenou a dokonca údajným konfliktom záujmov to môže vyzerať ako kompromitácia Core developerov. No nie je to tak.
Aby som to priblížil, predstavte si, že pracujete v slušnej firme, kde manžment zvážiac pre a proti na svojich poradách rozhodne o určitom postupe práce. Celý záver vám vysvetlí a vy súhlasíte, že to má logiku a pustíte sa do práce. Dokonca, to všetko zverejnia pre kohokoľvek, kto má záujem sa o tom dozvedieť aj s vhodným kontaktom na možné pripomienky. Uprostred práce vám na pracovisko vtrhne zhluk neznámych ľudí, ktorí začnú tvrdiť, že to tak robiť nemáte a argumentujú vecami, ktoré úplne ignorujú realitu. Z vyjadrenia je jasné, že tému vôbec nemajú nštudovanú. Prišlo by vám to v pohode? Nebolo by azda vhodnejšie aby si dotyční naštudovali argumenty a logicky ich vyvrátili na určenom mieste skrz zverejnené kontaknté údaje? (Jasné, analógia má nepresnosť v tom, že Bitcoin nemá manažment, ale pointa je, že odpor bol prejavený na nevhodnom mieste nevhodným spôsobom.)
Čiže nie je to cenzúra, je to normálne moderovanie ľudí, ktorí sa nesprávajú slušne. Čo je navyše veľmi smutné, ani po upozornení, že sa to preberalo a že sú zverejnené argumenty za, som nevidel nikoho z odporcov zrušenia limitu sa ani len pokúsiť argumenty vyvrátiť. Ani jeden necitoval niektorý z argumentov a neukázal, prečo je chybný, hoci aj chybne. Vedel by som pochopiť, že si niekto nevšimol tú diskusiu, ale písať štýlom "jeden o voze, druhý o koze" aj po upozornení je veľmi zvláštne.
Samozrejme, je pravda, že blokovanie aspoň trochu zvyšuje náklady na pridávanie dát. Je teda teoreticky možné, že blokovanie je stále menšie zlo ako neblokovanie.
Pozrime najskôr na blokovanie pomocou soft forku: Na zabránenie ukladania ľubovoľných dát by sme museli vyžadovať dva krát toľko podpisov ako dnes. Za každý výstup ne-taproot transakcie (bežná má dva) by sme navýšili veľkosť aspoň o 97 bytov (33 pre kľúč, 64 pre podpis), čiže typicky 192 byteov na transakciu. To je viac ako dvojnásobok dnešného limitu pre výstup začínajúci OP_RETURN. Pre Taproot je to zložitejšie - museli by sme uložiť celý strom - všetky scripty, ich verzie a pre každý kľúč v nich zase podpis. No aj keby sme zobrali optimistický prípad, že žiadne scripty nie sú, museli by sme to dokázať, čo tiež zaberá 33B a spolu s podpisom by to opäť bolo 97.
Inými slovami, ak by dnes každá jedna transakcia pridala výstup začínajúci OP_RETURN maximálnej štandardnej dĺžky, veľkosť blokov by sa zmenšila menej ako keby bolo implementované blokovanie a navyše by so sebou neniesla extra cenu verifikácie či straty súkromia Taprootu. Dnes nemá každá transakcia výstup začínajúci OP_RETURN, takže táto zmena je úplne jasne horšia.
Aby bolo jasné, netvrdím, že niekto toto navrhol a nechcem tu strawmanovať. Pokiaľ viem, nikto to seriózne nerieši a nie je to reálny argument. Chcem len ukázať, že sa touto možnosťou nemá zmysel ďalej zaoberať.
Tak to zjemnime na pravidlá štandardnosti a skutočný argument: "aspoň je to ťažšie". Problém je, že ide o software - keď raz existuje naprogramovaný nástroj aby niečo uľahčil, od toho momentu to navždy bude ľahké. No a tu je možnosť pre mining pooly či veľkých solo minerov získať výhodu: Naprogramujú web stránku, kde používateľ zadá svoje dáta, pošle BTC či už na adresu alebo pomocou LN a miner to vyminuje. Niečo také urobiť je pomerne jednoduché, trúfam si povedať, že by som funkčný základ dokázal urobiť najneskôr za pár dní.
V momente, keď existuje takáto stránka, sa výhoda blokovania trvalo stratila a ostala iba nevýhoda. A čo čert nechcel, aj keby sa limit potom zrušil, stále existuje funkčný nástroj, ktorý zvýhodňuje niektorých minerov a jediný spôsob ako ho poraziť je urobiť konkurenčný, lepší nástroj, ktorý poskytuje tú istú službu za lepších podmienok. Tento nástroj by samozrejme mohol vytvoriť konkurenčný miner, ale malý na to nebude mať peniaze. Musela by komunita bitcoinerov dobrovoľne takúto vec zafinancovať a spravovať. Blokovanie by tak maximálne pozastavilo ukladanie dát na možno pár týždňov.
Som presvedčený, že to za to nestojí.
Hore som uviedol podrobnú analýzu hlavnej línie rozporu a argumentov, no medzi argumentami proti sa objavili aj iné, ktoré do nej nezapadajú.
Nechcem. Mňa vážne nezaujíma, že na opačnej strane planéty Jožo poslal Ferovi opicu, ba nezaujíma ma ani, že poslal BTC. Nechcem platiť za drahší HW len preto, aby som tieto nezmysly spracoval. A to platí snáď pre každého vývojára Bitcoinu. No iná možnosť proste nie je. Tak, ako by som chcel vzlietnuť iba zamávaním rúk, no nedá sa to.
Tento argument je chybný, pretože zločinci majú vážne následky, ak spáchajú zločin a sú chytení. Čiže páchať zločiny je rizikové (drahé) a to ich reálne drží na uzde. Ak však niekto len vytvorí transakciu, ktorá je zablokovaná ako spam, nič sa mu nestane. Stratí maximálne tak čas, ktorý strávil jej tvorbou a dokonca môže skúsiť zase nájsť inú metódu, ktorá zafunguje. A keď je už raz metóda známa, môže sa rozšíriť a môže ju používať viacero ľudí.
No argument je chybný aj preto že, ako som popísal vyššie, dôsledky boja proti nefinančným dátam sú horšie.
Presnejšie, argument je, že niektoré súbory sú dnes ilegálne a používatelia môžu mať kvôli nim problémy a, hoci je možné ilegálny súbor uložiť do time chainu, v súčasnosti musí byť rozkúskovaný.
V prvom rade, právnik Radim Kozub, ktorého asi niektorí poznáte z jeho aktivít v Paralelní Polis, mi potvrdil, že len mať dáta na disku ako súčasť inej aplikácie (nie priamo dostupné) nie je ilegálne (Pozor, toto nie je právna rada!) Ale keby aj bolo, argument má ďalšie problémy.
Ak by to bola pravda, tak by existoval spôsob ako zločinci môžu ukladať a šírť nelegálny obsah: stačí ho rozdeliť na časti. Myslíte, že by na súde uspel nejaký šíriteľ ilegálnych súborov s argumentom "ten súbor nebol ilegálny, lebo bol rozdelený na časti"? Ja osobne neverím. Ale keby aj, typický príklad takého obsahu sú obrázky. Ak by niekto v takom ilegálnom obrázku zmenil kažý 173. pixel na červený, stal by sa legálnym? Tu je príklad, ako taký obrázok vyzerá.
Radim potvrdil, že obrázok, ktorý vyzerá prakticky rovnako je stále ilegálny - pár bodiek to nezmení. No a tento obrázok je možné už dnes vložiť do time chainu tak, že bude mať údaje nasledujúce po sebe. Čiže tento problém už v Bitcoine je a odstránením (zväčšením) limitu sa nezmení.
Proti argument proti tomuto bol, že je to náročné. No opäť, stačí aby to urobil jediný človek a celý Bitcoin je "infikovaný". A náročné to nie je, keď som robil ten príklad, kód napísal ChatGPT a fungoval bezchybne na prvý krát.
Navyše, celý zmysel Bitcoinu je vyhnúť sa vplyvu štátu na financie. Ak niekto beží full node takým spôsobom, že ho štát môže reálne skenovať, či nebodaj ovplyvňovať, tak nepochopil Bitcoin a potenciálne zvyšuje riziká pre ostatných bitcoinerov. Možno je to hnusné, ale taký človek si problémy snáď aj zaslúži.
Trochu iná, asi rozumnejšia, verzia argumentu je, že rôzne skenovacie nástroje by zbytočne nahlasovali také súbory, aj keď sú v poriadku. To je síce asi pravda, ale aplikuje sa iba na ľudí, ktorí také nástroje spúšťajú - to nie je typické použitie, no uznávam, že nie ani vylúčené. No títo ľudia majú možnosť súbory zamaskovať proti takýmto nástrojom. Dokonca, je to automatické pre tých, čo nestiahli dáta veľmi dávno. A aj tí, čo stiahli, majú hneď dve možnosti ako to vyriešiť (zmazať stiahnuť nanovo, alebo použiť nedávno vydaný nástroj). Nezabúdajme však, že tento problém Bitcoin už má teraz. Limit pre výstup, ktorého script začína OP_RETURN to nezmení.
No aj tak, nie je to argument proti (veľkým) scriptom začínajúcim OP_RETURN, ale maximálne pre jeho oddialenie, kým nebude podpora maskovania lepšia. Teda, aj to stojí na vratkých nohách, ale budiž, oddialiť vydanie kvôli tomu by som si vedel predstaviť.
V prvom rade by som chcel upozorniť, že konflikt záujmov hneď neznamená, že je niečo zlé. Ak výrobca trianglov (hudobný nástroj) povie, že Pytagorova veta platí, tak to predsa neznamená, že by neplatila, alebo že "lobuje za Pytagorovu vetu". Každopádne, áno, návrh zrušiť limit zahŕňal spomenutie protokolu a jeden z jeho developerov súhlasí s návrhom. Čo ale tento protokol reálne získa? Ak by ho prerobili, aby používal výstup, ktorého script začína OP_RETURN, ušetrili by maličké množstvo satoshi ale stálo by ich to prerábku, aspoň niekoľko hodín spolu s testami a nebodaj ešte auditom.
Zmena pre nich takmer nemá zmysel. (Aj preto treba konať čím skôr - ak to zmenia ešte pred vydaním, bude to pre nich lacnejšie a akceptovateľnejšie.) No a teraz po nich Core developeri vlastne chcú, aby to prerobili z dobrej vôle, že to nebude zaťažovať sieť. Na druhej strane ich iní ľudia očierňujú a možno keď zmenu urobia, budú za zlých. Smutný stav.
No aj keby tam konflikt záujmov bol, je to len jeden developer z mnohých.
Pretože limit je možné obísť už dnes a jeden zo spôsobov obchádzania je bežať fork Bitcoin Core, ktorý ho nemá, sú tieto katastrofálne následky možné už dnes, bez zmeny. Ak má niekto dôvod veriť, že katastrofálne následky sú možné, odporúčam predať (a zdaniť!) všetok Bitcoin.
Toto je celkom relevantná otázka. Ak je ten limit zlý, za normálnych okolností by sa nemal vynucovať, ale mala by ostať možnosť pre ľudí ho zapnúť. Zvyčajne som za konfigurovateľnosť, ale dáva to tu logiku? Kto zapne limit:
Naozaj sa niekto taký nájde? Z PR vidíme, že takí ľudia sú, čo zjavne nikto nečakal. Udržiavať nezmyselné konfiguračné voľby má svoju cenu - viac času strávia developeri ich správou, namiesto toho aby robili niečo iné. Je teda prirodzené, že Peter Todd navrhol rovno odstrániť aj tieto konfiguračné voľby.
Každopádne, hoci si myslím, že by bolo lepšie ich odstrániť, ponechať ich by nemal byť veľký problém. Ten pull request sa už zrušil a nový konfiguračné voľby ponechá, iba zmení predvolenú hodnotu.
Dúfam, že aj vy odteraz patríte k ľuďom, ktorí rozumejú Bitcoinu natoľko, že viete prísť k odpovedi: limit je škodlivý a treba ho zrušiť. Chápem, že takéto jednoznačné odpovede sú nezvyčajné a asi sa nájdu ľudia, ktorí si stále nebudú istí. No faktom je, že logicky vyplývajú z toho, ako funguje Bitcoin, siete, fyzika a matematika. Podobne ako Pytagorova veta teiž logicky vyplýva z matematických axióm. V každom prípade, držím vám všetkým palce so štúdiom Bitcoinu a robením správnych rozhodnutí ohľadom bežania full node. :)
Na záver chcem ešte poďakovať všetkým ľuďom, ktorí akoukoľvek formou prispeli k vytvoreniu tohoto článku.
