Befagyott a Bitcoin fejlesztése? A Drivechain alkotója szerint egyetlen soft fork sem tud átmenni
A vitát legutóbb a BIP-110 kudarca élezte ki. A Bitcoin blokkláncán tárolható nem pénzügyi adatok korlátozására létrehozott javaslat mindössze körülbelül 2,5 százalékos bányásztámogatást szerzett a döntő jelzési időszakban, majd az azt kikényszerítő kisebbségi lánc leszakadt a domináns Bitcoin-hálózatról. Az eset ismét megmutatta, milyen nehéz ma olyan protokollmódosítást elfogadtatni, amelyhez fejlesztők, bányászok, node-üzemeltetők és felhasználók széles körének együttműködésére van szükség.
A BIP-110 kudarca túlmutat egyetlen Bitcoin-frissítésen
Paul Sztorc szerint a BIP-110 történetét nem érdemes egy elszigetelt, sikertelen Bitcoin-fejlesztési kísérletként kezelni. A szakember arra hívta fel a figyelmet, hogy a Taproot 2021-es aktiválása óta több soft fork javaslat került a közösség elé, de egyik sem jutott el tényleges aktiválásig a domináns Bitcoin-hálózaton.
A soft fork olyan visszafelé kompatibilis protokollmódosítás, amely szigorítja vagy kiegészíti a hálózat konszenzusszabályait. A régebbi szoftvert futtató node-ok bizonyos feltételek mellett továbbra is képesek ugyanazt a blokkláncot követni, ezért egy soft fork technikailag kevésbé radikális változás, mint egy hard fork, amely összeegyeztethetetlen szabályrendszerekre szakíthatja a hálózatot.
A BIP-110, hivatalos nevén Reduced Data Temporary Softfork, ideiglenesen korlátozta volna a Bitcoin-tranzakciókban tárolható bizonyos adattípusokat. A tervezet mögötti alapgondolat az volt, hogy a Bitcoin blokkterületét elsősorban monetáris tranzakciókra kellene használni, és korlátozni kellene például az inscriptions és más, nem kifejezetten pénzügyi célú adatok blokkláncba írásának egyes módszereit.
A javaslat több új konszenzusszabályt vezetett volna be hozzávetőleg egyéves időtartamra. Egyebek mellett 83 bájtra korlátozta volna bizonyos OP_RETURN kimenetek méretét, egyes adatpush műveleteknél 256 bájtos plafont alkalmazott volna, és a Taproot bizonyos funkcióit is érintette volna.
A terv aktiválási mechanizmusa legalább 55 százalékos bányászjelzést várt el egy 2016 blokkból álló nehézségállítási periódusban. Ez azonban messze nem teljesült: a döntő időszakban mindössze 51 blokk jelezte a támogatást, ami körülbelül 2,53 százalékos aránynak felelt meg.
Sztorc ezért a BIP-110 kudarcát egy jóval szélesebb problémakör tünetének tekinti. Megfogalmazása szerint „a Taproot óta minden soft fork aktiválása kudarcot vallott”, a BIP-110 pedig egyszerűen ennek a sorozatnak a következő példája volt.
Két blokk után gyakorlatilag megállt a kisebbségi lánc
A BIP-110 története azonban nem ért véget az alacsony támogatottságnál. A javaslatot kikényszerítő node-ok 2026 augusztusában elkezdtek elutasítani olyan blokkokat, amelyek nem feleltek meg az általuk megkövetelt jelzési feltételeknek, miközben a Bitcoin bányászati kapacitásának túlnyomó többsége tovább építette a megszokott fő láncot.
A két szabályrendszer ennek következtében a 961 632-es blokk környékén elvált egymástól. A BIP-110 szabályait kikényszerítő ág az első órákban mindössze két blokkot tudott előállítani, miközben a domináns Bitcoin-lánc zavartalanul haladt tovább.
A probléma egyik legfontosabb oka a Bitcoin bányászati nehézsége volt. A kisebbségi lánc ugyanazt a rendkívül magas nehézségi szintet örökölte, amelyet az egész globális Bitcoin-hashráta kiszolgálására állított be a protokoll, miközben csak töredéknyi számítási kapacitás maradt rajta.
Normál körülmények között a Bitcoin nagyjából tízpercenként állít elő egy új blokkot, a nehézség pedig 2016 blokkonként módosul annak érdekében, hogy ezt az átlagos ütemet fenntartsa. Ha azonban egy lánc hirtelen elveszíti hashrátájának szinte egészét, miközben a nehézsége változatlan marad, az új blokkok közötti idő drasztikusan megnőhet.
Pontosan ez történt a BIP-110 ágával. A domináns Bitcoin-hálózat több mint száz blokkal járt előrébb, miközben a kisebbségi ág hosszú ideig gyakorlatilag mozdulatlan maradt, és csak napok alatt sikerült újabb blokkokat előállítania.
A történet azonban az eredeti soft fork kudarca után újabb fordulatot vett. A kisebbségi lánc augusztus 30-án a 961 640-es blokknál lecserélte a Bitcoin SHA-256d proof-of-work algoritmusát BLAKE2b-re, és ezzel már egy, a Bitcoin domináns hálózatával összeegyeztethetetlen hard forkot hozott létre.
Ez fontos különbség. A BLAKE2b-alapú lánc további működése nem azt jelenti, hogy a BIP-110 sikeresen aktiválódott volna a Bitcoinon: a globális Bitcoin-hálózat továbbra is a megszokott SHA-256d konszenzust használja, a BIP-110-ből kinőtt ág pedig külön szabályrendszerrel működik.
Miért vált ennyire nehézzé egy Bitcoin soft fork aktiválása?
A Bitcoin egyik legnagyobb erőssége egyben a fejlesztés egyik legnagyobb akadálya is. A hálózatnak nincs vezérigazgatója, központi fejlesztőcsapata vagy olyan irányító testülete, amely egyszerű többségi szavazással kötelező protokollfrissítést rendelhetne el minden résztvevő számára.
Egy jelentős konszenzusváltozáshoz fejlesztők, bányászok, teljes node-okat futtató szereplők, tőzsdék, tárcaszolgáltatók és végső soron a felhasználók széles körének kell elfogadhatónak tartania a módosítást. Ez a magas belépési küszöb megnehezíti a hálózat szabályainak önkényes megváltoztatását, ugyanakkor azt is jelenti, hogy egy technikailag hasznosnak tartott fejlesztés akár éveken keresztül vita tárgya maradhat.
A legutóbbi nagy sikeres Bitcoin soft fork, a Taproot 2021. november 14-én, a 709 632-es blokknál aktiválódott. A frissítés Schnorr-aláírásokat és új Taproot-költési szabályokat vezetett be, amelyek többek között hatékonyabbá és bizonyos esetekben privátabbá tehetik az összetett Bitcoin-tranzakciókat.
A Taproot aktiválását egy Speedy Trial néven ismert folyamat előzte meg, amelyben a bányászok jelezhették, készen állnak-e az új szabályokra. A szükséges támogatási küszöböt sikerült elérni, így a frissítés komoly láncszakadás nélkül lépett életbe.
Azóta azonban lényegesen nehezebbnek bizonyult hasonlóan széles egyetértést kialakítani új konszenzusváltozások mögött. Sztorc ebből arra következtet, hogy maga a Bitcoin frissítési mechanizmusa került egy olyan állapotba, ahol az elutasítás vagy a döntés elhalasztása könnyebb, mint a változtatáshoz szükséges koordináció.
Ennek megítélése ugyanakkor nézőpont kérdése. Ami az egyik fejlesztő számára technológiai stagnálás, azt egy másik Bitcoin-felhasználó a monetáris rendszer kiszámíthatóságának és változtatásokkal szembeni ellenálló képességének tekintheti.
Még az OP_CAT sem jutott át a konszenzusfalon
Sztorc egyik legfontosabb példája az OP_CAT, amely technikailag jóval kisebb változás lenne, mint számos más Bitcoin-fejlesztési elképzelés. Az opcode lehetővé tenné, hogy a Bitcoin Script két adatelemet összekapcsoljon, ami új programozhatósági lehetőségeket teremthetne.
Az OP_CAT ráadásul nem teljesen új ötlet. A művelet szerepelt a Bitcoin eredeti szoftverében is, Satoshi Nakamoto azonban 2010-ben biztonsági megfontolások miatt letiltotta több más opcode-dal együtt.
Az OP_CAT visszaállításának támogatói szerint az opcode többek között fejlettebb covenantok, biztonságosabb trezorok, hidak és összetettebb költési feltételek kialakítását segíthetné. A covenant lényegében olyan Bitcoin-szabály, amely nemcsak azt határozza meg, ki jogosult elkölteni egy érmét, hanem bizonyos mértékig azt is, hogyan vagy milyen feltételekkel lehet azt később továbbmozgatni.
Sztorc szerint ugyanakkor még egy ilyen, viszonylag kis kódmódosítás sem képes átjutni a Bitcoin konszenzusfolyamatán. A Drivechain alkotója ezért úgy fogalmazott, hogy véleménye szerint a Bitcoin „belátható időn belül nem képes egyetlen soft forkot sem aktiválni”.
Ez természetesen Sztorc értékelése, nem pedig bizonyított technikai korlát. Nincs olyan protokollszabály, amely megakadályozná egy jövőbeli soft fork aktiválását, amennyiben mögötte elegendő társadalmi, gazdasági és technikai támogatás alakul ki.
A vita sokkal inkább arról szól, hogy létrejöhet-e a gyakorlatban ilyen széles körű konszenzus. Az OP_CAT évek óta tartó egyeztetése azt mutatja, hogy még a fejlesztői körökben jelentős támogatással rendelkező ötletek esetében sem egyszerű meghatározni az elfogadható aktiválási módszert.
A kvantumszámítógépek elleni védelem is konszenzust igényel
Ugyanezzel a problémával találkozhatnak azok a fejlesztések is, amelyek nem elsősorban új funkciókat adnának a Bitcoinnak, hanem hosszabb távú biztonsági kockázatok ellen készítenék fel. Ide tartozik például a BIP-360, amely egy Pay-to-Merkle-Root, vagyis P2MR nevű új kimenettípust javasol.
A BIP-360 célja a Bitcoin bizonyos, jövőbeli kvantumszámítógépes támadásokkal szembeni ellenálló képességének javítása. A konstrukció eltávolítaná a Taproot által használt, kvantumszempontból sebezhetőbb key-path költési módot, miközben megtartaná a scriptfa-alapú funkcionalitás jelentős részét.
Ez önmagában még nem tenné teljesen kvantumbiztossá a Bitcoint. A fejlesztők szerint azonban egy lehetséges első lépést jelenthetne egy olyan rendszer felé, amely később posztkvantum-aláírási megoldásokkal egészíthető ki.
A BIP-360 példája azért különösen érdekes, mert megmutatja, hogy a konszenzusprobléma nem kizárólag opcionális vagy kísérleti funkciókat érinthet. Ha a jövőben ténylegesen szükségessé válna egy fontos biztonsági frissítés, annak bevezetése ugyanúgy széles körű Bitcoin-konszenzust igényelne.
Ez nem jelenti azt, hogy a hálózat képtelen lenne reagálni egy valódi és közvetlen veszélyhelyzetre. Egy egyértelmű technikai fenyegetés lényegesen erősebb ösztönzőt teremthetne az együttműködésre, mint a jelenlegi fejlesztési javaslatok, amelyek előnyeiről és hátrányairól jóval több vita folyik.
A Drivechain kivinné a kísérletezést a Bitcoin alaphálózatáról
Sztorc saját megoldása erre a problémára a Drivechain, amelynek célja éppen az lenne, hogy ne kelljen minden új Bitcoin-funkció miatt megváltoztatni az alaphálózat szabályait. A fejlesztők ehelyett külön, opcionálisan használható sidechaineken próbálhatnának ki új technológiákat.
A sidechain, vagyis oldallánc egy olyan különálló blokklánc, amely valamilyen mechanizmus segítségével kapcsolatot tart fenn a Bitcoin fő hálózatával. A felhasználó BTC-t mozgathatna a fő láncról az adott sidechainre, használhatná annak speciális funkcióit, majd megfelelő feltételek mellett visszavihetné érméit a Bitcoin alaphálózatára.
A BIP-300 a Drivechain egyik központi eleme, amely egy úgynevezett kétirányú peg segítségével kapcsolná össze a Bitcoint a különböző oldalláncokkal. Az egyes Drivechainek saját szabályrendszert alkalmazhatnának, így elméletileg fejlettebb adatvédelmi rendszerek, okosszerződések, gyorsabb tranzakciók vagy akár teljesen új gazdasági modellek is kipróbálhatók lennének rajtuk.
Ennek egyik legnagyobb előnye az elképzelés támogatói szerint az, hogy egy új funkció használatához nem kellene minden Bitcoin-tulajdonosnak elfogadnia ugyanazokat a szabályokat. Aki nem érdeklődik egy adott Drivechain iránt, egyszerűen figyelmen kívül hagyhatná azt.
Sztorc ezt a jelenlegi Layer 2 rendszerekhez, például a Lightning Networkhöz, valamint az olyan sidechainekhez hasonlítja, mint a Liquid. Minden egyes rendszernek saját neve, szoftvere, közössége és kockázati profilja lenne, miközben a BTC szolgálhatna közös monetáris eszközként.
Ez egyúttal választ adhatna arra az aggályra is, hogy több Drivechain szétaprózná a Bitcoin likviditását. Sztorc szerint ez nem feltétlenül különbözik attól, hogy ma számos különálló Layer 2, sidechain és altcoin versenyez a felhasználókért.
A Drivechainnek ugyanazt a falat kellene először áttörnie
A Drivechain koncepcióban azonban van egy alapvető paradoxon. Ahhoz, hogy a jövőben kevesebb Bitcoin soft forkra legyen szükség, először magát a Drivechaint kellene egy Bitcoin-konszenzusmódosítással aktiválni.
Vagyis a BIP-300 pontosan ugyanabba a koordinációs problémába ütközik, amelyet megpróbálna részben megoldani. Ha Sztorcnak igaza van abban, hogy jelenleg gyakorlatilag egyetlen új soft fork sem tud elegendő támogatást szerezni, akkor a Drivechain sem tud könnyen bekerülni a Bitcoin konszenzusszabályai közé.
Amikor arról kérdezték, hogyan tudná a BIP-300 leküzdeni azt az ellenállást, amely más javaslatok aktiválását is megakadályozta, Sztorc lényegében elismerte ezt a problémát. Véleménye szerint jelenleg erre nincs egyszerű technikai megoldás, mivel a fő akadály nem maga a kód, hanem a szükséges társadalmi konszenzus hiánya.
Ez jól példázza a Bitcoin fejlesztésének egyik különleges tulajdonságát. Egy technikailag működő megoldás önmagában nem elegendő: a konszenzusszabályok megváltoztatásához a hálózat gazdasági szereplőinek is elfogadhatónak kell tartaniuk annak kockázatait és előnyeit.
A bányászok szerepe a Drivechain legnagyobb vitája
A Drivechain másik vitatott pontja a Bitcoin-bányászok szerepe. A BIP-300 jelentős feladatot adna nekik a sidechainekről a Bitcoin alaphálózatára történő visszautalások jóváhagyásában.
A modellben a sidechainről érkező BTC-kivonási kérelmek egy ideig függő állapotban maradnának, miközben a bányászok Bitcoin-blokkokon keresztül szavaznának róluk. Ha egy kifizetés a szükséges időszak alatt megfelelő támogatást szerezne, a BTC felszabadulhatna a sidechainhez tartozó letéti konstrukcióból.
A kritikusok szerint ez túl nagy befolyást adhat a bányászoknak, és elméletileg megteremtheti egy összehangolt, szabálytalan kivonás lehetőségét. Ha elegendő bányász együttműködne, megpróbálhatnának olyan BTC-t felszabadítani, amelyre a sidechain szabályai szerint nem lennének jogosultak.
Sztorc érvelése szerint a rendszer biztonságát részben a gazdasági ösztönzők biztosítanák. Ha egy Drivechain népszerű, és jelentős tranzakciós díjbevételt termel a Bitcoin-bányászok számára, akkor a bányászoknak hosszabb távon többet érhet a rendszer tisztességes fenntartása, mint annak egyszeri megtámadása.
Más szóval a biztonsági modell részben arra épül, hogy egy sikeres sidechain jövőbeli díjbevétele gazdaságilag értékes. Minél nagyobb ez a bevétel a sidechainen lekötött BTC mennyiségéhez képest, Sztorc szerint annál kevésbé vonzó egy támadás.
Ez azonban nem szünteti meg teljesen a kockázatot. A felhasználóknak továbbra is mérlegelniük kellene, mekkora érték található a pegben, milyen díjbevételek ösztönzik a bányászokat, és milyen körülmények között válhatna gazdaságilag racionálissá egy összehangolt támadás.
A BIP-110 megmutatta, hogy egy sikertelen fork sem veszélytelen
A BIP-110 történetének van egy további tanulsága is: már egy sikertelen kisebbségi láncszakadás is technikai veszélyeket teremthet a felhasználók számára. Az eredeti BIP-110 fork ugyanis nem rendelkezett automatikus replay protectionnel.
A replay attack ebben az esetben azt jelenti, hogy egy felhasználó az egyik láncon aláír egy tranzakciót, amelyet megfelelő körülmények között a másik láncon is újra lehet közvetíteni. Ha a két blokklánc ugyanazokat a kulcsokat és tranzakcióformátumokat fogadja el, egy rosszul kezelt fork során a felhasználó nemcsak a kisebbségi láncon lévő érméit, hanem valódi BTC-jét is veszélyeztetheti.
Ezért a láncszakadások során különösen fontos az úgynevezett coin splitting, vagyis annak biztosítása, hogy a két ágon található érmék külön-külön mozgathatók legyenek. Enélkül egy kisebbségi fork tokenjeinek eladása vagy mozgatása váratlan következményekkel járhat a domináns Bitcoin-láncon is.
A BIP-110-ből kialakult ág későbbi BLAKE2b-váltása egyértelműbb technikai elválást hozott létre, hiszen az új proof-of-work algoritmus már nem kompatibilis a Bitcoin SHA-256d bányászati rendszerével. Ettől azonban az ág nem vált a Bitcoin hálózat által elfogadott soft forkká, hanem önálló konszenzusszabályokkal működő külön lánccá alakult.
Tényleg „befagyott” a Bitcoin fejlesztése?
Sztorc állítása mögött valós probléma húzódik meg: a Bitcoin alapprotokolljának megváltoztatása ma rendkívül magas konszenzusküszöböt igényel. A BIP-110, az OP_CAT, a BIP-300 és a kvantumrezisztenciát célzó javaslatok mind különböző célokat szolgálnak, mégis ugyanazzal az alapvető kérdéssel találják szembe magukat: ki és milyen folyamatban döntheti el, mikor érett meg egy változtatás az aktiválásra?
Ebből ugyanakkor nem következik automatikusan, hogy a Bitcoin technológiai fejlődése teljesen leállt volna. A hálózat körüli innováció jelentős része már most is az alapprotokoll módosítása nélkül zajlik, például a Lightning Networkön, sidechaineken, új tárcatechnológiákon, aláírási megoldásokon vagy az alkalmazási rétegekben.
A vita mélyén ezért két eltérő fejlesztési filozófia ütközik. Az egyik szerint a Bitcoin alaphálózatának képesnek kell lennie új funkciók és biztonsági fejlesztések fokozatos befogadására, míg a másik megközelítés szerint éppen a rendkívül lassú és nehéz változtathatóság védi a Bitcoint attól, hogy rövid távú érdekek vagy vitatott technológiák túl könnyen átírják monetáris szabályait.
A BIP-110 kudarca mindenesetre erős példát szolgáltat arra, hogy egy Bitcoin-konszenzusmódosításhoz nem elegendő néhány fejlesztő támogatása vagy egy működőképes kód. Szélesebb gazdasági és társadalmi elfogadottság nélkül még egy technikailag megvalósítható soft fork is könnyen kisebbségi lánccá válhat.
A következő nagy Bitcoin-frissítés ezért nemcsak technológiai kérdés lesz. Ugyanilyen fontos lesz az is, hogy a közösség képes-e olyan aktiválási folyamatot kialakítani, amelyet a bányászok, node-üzemeltetők, fejlesztők és felhasználók kellően nagy része legitimnek és biztonságosnak fogad el.
