A Bitcoint gyakran digitális aranyként írják le, ami statikus és változtathatatlan természetet sugall. Azonban a Bitcoin hálózatot működtető szoftver egy élő protokoll, amely karbantartáson, hibajavításokon és frissítéseken esik át. Ellentétben a centralizált szoftverfejlesztéssel, ahol egy vállalati vezérigazgató vagy termékmenedzser diktálja a funkciókat, a Bitcoin egy decentralizált résztvevői hálózatra támaszkodik a változások elfogadásához. Ez a folyamat szándékos, lassú, és erősen a status quo felé hajlik, hogy biztosítsa milliárdok dollárnyi érték biztonságát.
A protokoll fejlődését nem formális szavazási rendszer vagy egyetlen hatóság irányítja. Ehelyett egyedi kombináción keresztül működik: technikai dokumentáció, szakértői áttekintés és közösségi konszenzus. Az megértése, hogy egy ötlet hogyan jut el egy egyszerű levelezési listás megbeszéléstől egy globálisan aktivált kódbeli változásig, feltárja a Bitcoin hálózat ellenálló képességét. Kiemeli azt a rendszert, amelyet arra terveztek, hogy ellenálljon bármely egyetlen csoport elfogásában, legyenek azok fejlesztők, bányászok vagy vállalati érdekek.
Evolutionary folyamat középpontjában a Bitcoin Improvement Proposal, azaz BIP áll. Ez a fő mechanizmus az új funkciók javaslására, a közösségi visszajelzések gyűjtésére egy problémára vonatkozóan, valamint a tervezési döntések dokumentálására. A BIP nem kötelező erejű szavazás, hanem technikai tervezési dokumentum. Információt biztosít a Bitcoin közösség számára, vagy leírja a Bitcoin vagy folyamatai új funkcióját.
A Bitcoin Improvement Proposal keretrendszer
Ahhoz, hogy megértsük, hogyan változik a Bitcoin, először meg kell értenünk a szabványosítási folyamatot. A BIP rendszer erősen befolyásolva van a Python Enhancement Proposal (PEP) folyamattól. Formális módot biztosít a kódbázisban vagy a környező ökoszisztémában bevezetendő változásokra. Bárki írhat BIP-et, de annak elfogadása és megvalósítása szigorú megmérettetés, amelyet kevés javaslat él túl.
A BIP meghatározása
A BIP lényegében egy technikai dokumentum. Tömör technikai specifikációt kínál a funkcióra és indoklást a funkcióra. A szerző felelős a közösségen belüli konszenzus kialakításáért és a dissenting vélemények dokumentálásáért. Három fő BIP-típus létezik. A Standards Track BIP-ek minden vagy legtöbb Bitcoin-implementációt érintő változást írnak le, például hálózati protokoll-változást vagy blokk- vagy tranzakció érvényességi szabályok változását.
Az Informational BIP-ek egy Bitcoin tervezési problémát írnak le, vagy általános iránymutatást vagy információt nyújtanak a Bitcoin közösségnek, de nem javasolnak új funkciót. A Process BIP-ek a Bitcoin körül lévő folyamatot írják le, vagy folyamatváltozást vagy eseményt javasolnak. A nyilvános figyelem nagy része a Standards Track BIP-ekre irányul, mivel ezek módosítják a hálózat konszenzus szabályait.
Egy javaslat életciklusa
Egy BIP élete hosszú idővel a számozása előtt kezdődik. Általában a Bitcoin fejlesztői levelezési listán folyó megbeszélésekkel indul. Itt vetik alá kezdeti ötletet a bírálatnak, kritikának, és gyakran széttépik más fejlesztők. Ha az ötlet túléli ezt a kezdeti tűzpróbát, a szerző megírja a BIP szövegét.
Miután a vázlatot benyújtják a BIP adattárba, egy szerkesztő számozást rendel hozzá. Ez a státusz „Draft”. Innen a javaslat különböző szakaszokon megy keresztül. Ha a közösség értékesnek tartja a munkát, „Proposed”-ra léphet. Ha a változásokat megvalósítják és a hálózat aktiválja őket, a BIP „Final” vagy „Active” lesz. Ellenkező esetben a javaslatot „Rejected”-ként, a szerző által „Withdrawn”-ként jelölhetik, vagy „Obsolete”-ként, ha újabb megoldások váltják fel.
A konszenzus mechanizmusa
A Bitcoin fejlesztés legzavarba ejtőbb aspektusa a kívülállók számára a formális kormányzati struktúra hiánya. Nincs alapítvány vagy vezető, aki „jóváhagyott” pecsétet üt egy BIP-re. Ehelyett a hálózat a „rough consensus” nevű koncepcióra támaszkodik. Ez egy kifejezés az Internet Engineering Task Force-tól (IETF). Nem jelenti az egyhangúságot.
A rough consensus megértése
A rough consensus akkor jön létre, ha a technikai közösség általában egyetért abban, hogy a javaslat szilárd, és minden jelentős kifogást orvosoltak. Kvalitatív mérés, nem mennyiségi szavazás. Ha egy javaslat erős technikai érdemekkel bír, de jelentős fejlesztői csoport valid biztonsági aggályokat fogalmaz meg, nem halad tovább.
Ez a dinamika arra kényszeríti a szerzőket, hogy foglalkozzanak a kritikusokkal. Javítaniuk kell a javaslatukat, amíg a kifogásokat meg nem oldják vagy alaptalannak nem bizonyítják. Ez a folyamat évekig tarthat. Például a Taproot frissítést hosszú ideig beszélték meg és finomították, mielőtt aktiválásra készen állónak tekintették. A lassúság funkció, nem hiba, megakadályozza a meggondolatlan döntéseket, amelyek destabilizálhatnák a pénzügyi hálózatot.
Fejlesztői commit hozzáférés
Gyakori tévhit, hogy a Bitcoin Core GitHub tárolóhoz „commit access”-sel rendelkező fejlesztők irányítják a Bitcoint. Bár ezek a maintainer-ek egyesíthetik a kódot a fő ágba, inkább takarítók, mint uralkodók. Feladatuk biztosítani, hogy az egyesített kód tükrözze a közösség rough consensus-ét.
Ha egy maintainer olyan kódot egyesítene, amely alapvetően megváltoztatja a Bitcoint a felhasználók akarata ellenére, a node üzemeltetők egyszerűen visszautasítanák a frissítést arra a verzióra. A hálózat a korábbi verzión folytatódna, a maintainer verziója figyelmen kívül maradna. Ez erős ellenőrzést teremt a fejlesztői befolyással szemben, biztosítva, hogy a node hálózat kívánalmainak maradjanak hűek.
Aktiválás és megvalósítási utak
Miután egy protokollfrissítést kódoltak és beolvasztottak a Bitcoin Core szoftverbe, inaktív marad. A hálózatnak kell „aktiválnia”. Ez az a fázis, ahol a elméleti konszenzus találkozik a blokklánc fizikai valóságával. Az aktiváláshoz koordináció szükséges a rendszer gazdasági szereplői között, elsősorban a bányászok és teljes node üzemeltetők között.
Bányász jelzés és küszöbök
Történelmileg az aktiválás gyakran a BIP 9-ben meghatározott folyamatot használta. Ebben a bányászok jelzik készenlétüket a frissítésre a bányászott blokkfejlécben. Egy adott időszakban, általában két hét (2016 blokk) alatt a hálózat figyeli, hány blokk tartalmazza a frissítés támogatását jelző signalt.
Ha a jelző blokkok százalékos aránya eléri a meghatározott küszöböt – gyakran 90% vagy 95% –, a frissítés lock-in állapotba kerül. Egy későbbi kegyelmi időszak után az új szabályok aktívak lesznek. Ez a mechanizmus biztosítja a hálózat zökkenőmentes frissülését anélkül, hogy bányászokat hagyna lemaradva. Azonban politikai patthelyzetekhez is vezetett, ahol a bányászok vétózzák a frissítéseket a jelzés megtagadásával, még ha a szélesebb felhasználói bázis akarja is a változást.
Felhasználó által aktivált soft fork-ok
A bányász jelzés korlátai a „Block Size War” alatt váltak nyilvánvalóvá 2017 előtt. Amikor a bányászok visszatartották a Segregated Witness (SegWit) aktiválását, egy grassroots mozgalom indult User Activated Soft Fork (UASF) javaslattal, a BIP 148 néven ismerttel.
Egy UASF-ben a node üzemeltetők olyan szoftvert futtatnak, amely elutasítja azokat a blokkokat a bányászoktól, akik egy bizonyos dátum után nem jelzik a frissítést. Ez áthelyezi a hatalmat a bányászoktól a node-ok gazdasági többségéhez. Ha a gazdasági aktivitás (tőzsdék, tárcák, felhasználók) a UASF láncra költözik, a bányászokat gazdasági ösztönzés hajtja, hogy kövessék, vagy értéktelen láncot bányásznak. A BIP 148 fenyegetése kulcsfontosságú volt a SegWit aktiválásában.
Fork dinamikák és kompatibilitás
A Bitcoin protokoll változásai általában két kategóriába sorolhatók: soft fork-ok és hard fork-ok. A különbség a visszamenőleges kompatibilitásban rejlik. E különbség megértése kulcsfontosságú ahhoz, hogy miért maradt a Bitcoin egyetlen, folyamatos hálózat számos frissítés ellenére.
A soft fork mechanizmusa
A soft fork olyan protokollváltozás, amely szűkíti az érvényes blokkok halmazát. Megszigorítja a szabályokat. Mivel az új szabályok az öregek részhalmazai, a nem frissített régi node-ok továbbra is érvényesnek látják az új blokkokat. Lehet, hogy nem értik az új funkciókat, de elfogadják a láncot.
Ez a visszamenőleges kompatibilitás létfontosságú. lehetővé teszi a hálózat fokozatos frissülését. A felhasználókat nem kényszerítik azonnali szoftverfrissítésre a konszenzusban maradáshoz. A legtöbb jelentős frissítés, beleértve a SegWit-et és Taproot-ot, soft fork-ként valósult meg. Ez biztosítja, hogy a hálózat ne szakadjon két inkompatibilis láncra pusztán azért, mert néhány felhasználó lassan frissít.
A hard fork eltérés
A hard fork meglazítja a szabályokat vagy olyan szabályokat vezet be, amelyek inkompatibilisek a régi szoftverrel. A régi node-ok érvénytelennek tekintik az új szabályok alatt létrehozott blokkokat és elutasítják őket. Egy hard fork sikeréhez hálózatfelosztás nélkül 100%-ban egyidejűleg frissülniük kell a felhasználóknak, ami lehetetlen decentralizált rendszerben.
Ennek következtében a vitatott hard fork-ok szinte mindig tartós láncszakadáshoz vezetnek. A leghíresebb példa a Bitcoin Cash (BCH) létrehozása 2017-ben. A támogatók növelni akarták a blokkméret-határt, ami inkompatibilis volt a Bitcoin akkori konszenzusával. Ez két különálló hálózatot és pénznemet eredményezett. A hard fork-okat általában kerülik a Bitcoin fejlesztésben emiatt a hálózat és közösség széttörésének kockázata miatt.
| Összehasonlítási attribútum | Soft Fork | Hard Fork |
|---|---|---|
| Kompatibilitás | Visszamenőleg kompatibilis | Nem visszamenőleg kompatibilis |
| Szabályváltozás | Megszigorítja/korlátozza a szabályokat | Meglazítja/bővíti a szabályokat |
| Hálózati kockázat | Alacsony kockázatú láncszakadás | Magas kockázatú tartós szakadás |
Jelentős protokollfrissítések: Segregated Witness
Egy javaslat megvalósításához vezető egyik legjelentősebb példa a Segregated Witness (SegWit). 2017 augusztusában aktiválták, hosszú ideje fennálló problémákat oldott meg és megágyazott a jövőbeli skálázásnak. A javaslat alapvetően megváltoztatta a tranzakcióadatok struktúráját.
A malleability megoldása
SegWit előtt lehetséges volt módosítani egy tranzakció egyedi azonosítóját megerősítés előtt a blokkláncon anélkül, hogy érvénytelenné tenné az aláírást. Ez a tranzakció malleability probléma megnehezítette a második rétegű megoldások, mint a Lightning Network építését. Ha a tranzakció ID megváltozhatott, az azon alapuló smart contract-ek megtörtek volna.
A SegWit ezt úgy oldotta meg, hogy a aláírás (witness) adatot a tranzakció ID kiszámításához használt részén kívülre helyezte. A witness elkülönítésével a tranzakció ID megváltoztathatatlanná vált. Ez a javítás volt a kulcs, amely lehetővé tette a fizetési csatornák biztonságos működését, elősegítve a Lightning Network fejlesztését.
A súlyegység koncepció
A SegWit egyúttal okos blokkméret-növelést is jelentett. A 1MB limit egyszerű emelése helyett – ami hard fork-ot igényelt volna – a SegWit megváltoztatta a blokkok mérését. Bevezetette a „block weight”-et.
A witness szekció adatai kevesebb súlyt kapnak, mint a fő tranzakciós blokk adatai. Ez lehetővé teszi, hogy a blokkok meghaladják a hagyományos 1MB nyers adatméretet (elméletileg akár 4MB-ig), miközben kompatibilisek maradnak a csak non-witness adatokat ellenőrző legacy node-okkal. Ez hatékonyan növelte a hálózat kapacitását és csökkentette a SegWit formátumú tranzakciók díjait.
A Taproot frissítés
A SegWit után a következő jelentős változás a Taproot volt, amelyet 2021 novemberében aktiváltak. A Taproot három BIP-et (340, 341 és 342) egyesített a privacy, hatékonyság és scriptelési képességek javítására. Egy kifinomultabb aktiválási folyamatot demonstrált „Speedy Trial” néven.
Schnorr aláírások
A Taproot magja a Schnorr aláírások (BIP 340) implementációja. Ez a digitális aláírás séma jelentős előnyöket kínál az eredeti Elliptic Curve Digital Signature Algorithm (ECDSA) felett. A fő előny a linearitás.
A linearitás lehetővé teszi az aláírás aggregációt. Többaláírásos tranzakcióban több nyilvános kulcsot és aláírást egyetlen kulccá és aláírásává lehet kombinálni. A blokklánc számára egy több fél érintett összetett tranzakció azonosnak tűnik egy standard egyfelhasználós tranzakcióval. Ez növeli a privacy-t a tárca-elrendezések komplexitásának elrejtésével és helyet spórol a blokkláncon, csökkentve a díjakat.
Merkelized Abstract Syntax Trees
A Taproot bevezette a Merkelized Abstract Syntax Trees (MAST)-et is. Korábban, ha egy felhasználó összetett smart contract-et több költési feltétellel hozott létre, az összes feltételnek ki kellett tűnnie a blokkláncon a pénzköltéskor. Ez hatékonytalan és rossz a privacy szempontjából volt.
A MAST-tal a felhasználók fa struktúrában szervezhetik a költési feltételeket. Költéskor csak a használt faágat kell felfedniük. A nem használt ágak rejtve maradnak. Ez lehetővé teszi az összetett, privát és adat-hatékony smart contract-eket, tovább bővítve a Bitcoin potenciálját a egyszerű értékátvitel túl.
Jelenlegi viták: Az OP_CAT esete
A Bitcoin fejlődése folyik, a jelenlegi megbeszélések a elvesztett funkcionalitás helyreállítására összpontosítanak. Az egyik legkiemelkedőbb téma az OP_CAT. Ez egy specifikus opcode (műveleti kód), amely az eredeti Bitcoin szoftver része volt, de Satoshi Nakamoto 2010-ben letiltotta memóriahasználati és biztonsági aggályok miatt.
Opcode-ek megértése
Az opcode-ek a parancsok, amelyeket a Bitcoin script nyelv ért. Megmondják a hálózatnak, hogyan dolgozzon fel egy tranzakciót. Egyes opcode-ok összeadást tesznek lehetővé, mások aláírásokat ellenőriznek, néhány időzárakat. Ha egy opcode letiltásra kerül, az a specifikus művelet eltávolítását jelenti a hálózat eszköztárából.
Az OP_CAT és mások eltávolítása súlyosan korlátozta a Bitcoin script nyelvet. Ez a korlátozás szándékos volt akkoriban, a biztonságot és stabilitást helyezte előtérbe a funkcionalitás helyett. Azonban a protokoll megértésének éretté válásával a fejlesztők most a biztonságos újbóli bevezetést vizsgálják ezeknek a kódoknak új funkciók engedélyezésére.
A konkatenáció javaslat
Az OP_CAT specifikusan két adatstring összeillesztését (konkatenáció) teszi lehetővé. Bár egyszerűen hangzik, ez egy erős funkciót, „covenant”-eket tesz lehetővé. A covenant-ek korlátozásokat tesznek lehetővé arra, hogyan költhetők jövőben a bitcoinok, nem csak arra, ki költheti őket.
Például egy covenant kikényszerítheti, hogy egy specifikus UTXO csak egy whitelist címekre küldhető. Ennek hatalmas implikációi vannak vault mechanizmusokra, ahol felhasználók „visszavonás” gombot hozhatnak létre ellopott alapokra, és Layer 2 hidakra. Az OP_CAT körül folyó vita illusztrálja a Bitcoin fejlesztés konzervatív jellegét; még egy egyszerű parancshoz is évek biztonsági elemzése szükséges a bevezetés előtt.
Hatása a Layer 2 megoldásokra
A protokolljavaslatok gyakran az alapréteget célozzák, de elsődleges hasznosságuk a Layer 2 (L2) hálózatokon valósul meg. A fő blokklánc és ezek a másodlagos rétegek kapcsolata szimbiotikus. Az alapprotokoll javításai olcsóbbá, biztonságosabbá és hatékonyabbá teszik az L2-ket.
Lightning Network függőségek
A Lightning Network tökéletes példa erre a függőségre. Az alapréteg biztonságára támaszkodik a tranzakciók elszámolásához. Ahogy említettük, a SegWit frissítés előfeltétel volt a Lightning megbízható működéséhez. Jövőbeli frissítések továbbra is a Lightning hatékonyságát célozzák.
Például az „Eltoo” (SIGHASH_ANYPREVOUT) javaslatok egyszerűsítik a csatorna kezelést. Az alapréteg tranzakció-aláírásának módosításával a Lightning node-ok kevesebb adatot tárolhatnak és könnyebben helyreállhatnak hibákból. Ez mutatja, hogy az L1 javaslatokat gyakran az L2 skálázási igények hajtják.
Sidechain integráció
A sidechain-ek, mint a Liquid vagy Rootstock, szintén profitálnak a protokollfrissítésekből. A sidechain-ek független blokkláncok, amelyek párhuzamosan futnak a Bitcoinnal. Kétirányú peg-et használnak az érték átvitelére. Jelenleg ezek a peg-ek gyakran federációkra támaszkodnak – megbízott funkcionáriusok csoportjára.
Frissítések, mint az OP_CAT vagy új aláírás séma, lehetővé tehetik a trustlessabb hid mechanizmusokat. Ha a Bitcoin script ellenőrizhet sidechain proof-okat (mint Zero-Knowledge proof-ok), felhasználók láncok között mozgathatják alapjukat federáció nélkül. Ez jelentős kutatási terület és motiváció új BIP-ekhez.
Váratlan innováció: Az Ordinals jelenség
Néha a protokollfrissítések teljesen váratlan eredményekhez vezetnek. Az Ordinals felemelkedése tanúbizonysága a nyílt forráskódú szoftverben a unintended consequences törvényének. Az Ordinals a SegWit és Taproot mechanikáit használja fel adatok közvetlen felírására egyedi satoshikra.
A SegWit olcsóbbá tette a witness adatok tárolását, a Taproot eltávolította az adatpush méretkorlátot a tranzakció script-ekben. Ezek együtt lehetővé tették, hogy felhasználók képeket, szöveget, sőt videojátékokat ágyazzanak be a Bitcoin blokkláncba. Ez nem volt a BIP-eket író fejlesztők specifikus szándéka.
Ez a fejlemény heves vitát váltott ki a közösségben. Egyesek spamnek tekintik az inscriptions-okat, amelyek túlterhelik a hálózatot, mások legitim blokktér-használatnak látják díjakkal fizetve. Bármely nézőpont mellett, az Ordinals demonstrálja, hogy amint egy javaslat implementálva van, a hálózat felhasználói olyan módon használják az új szabályokat, amit a szerzők soha nem képzeltek meg.
Következtetés
Egy Bitcoin protokolljavaslat anatómiája egy olyan rendszert tár fel, amely a túlélést helyezi mindenek fölé. A BIP kezdeti megírásától a rough consensus kiépítésének strapás folyamatáig minden lépés a kockázatok kiszűrésére szolgál. A soft fork-ok és hard fork-ok közötti különbség a visszamenőleges kompatibilitás iránti elkötelezettséget mutatja, biztosítva, hogy a hálózat inkluzív maradjon előrehaladtával.
Frissítések, mint a SegWit és Taproot, mutatják, hogy a Bitcoin innoválhat core elveinek feláldozása nélkül. Közben az OP_CAT körüli folyó viták és az Ordinals megjelenése bizonyítja, hogy az ökoszisztéma vibráló és kiszámíthatatlan marad. A bányászok, fejlesztők és node üzemeltetők kölcsönhatása egyensúlyrendszert teremt, amit egyetlen centralizált entitás sem írhat felül.
A Bitcoin lassan változik nem azért, mert nem képes gyorsan mozogni, hanem mert túl magas a kockázata a megtörésének.