Bitcoin dažnai apibūdinamas kaip skaitmeninis auksas, kas reiškia statišką ir negalią keisti prigimtį. Tačiau programinė įranga, varanti Bitcoin tinklą, yra gyvas protokolas, patiriantis priežiūrą, klaidų taisymus ir atnaujinimus. Skirtingai nuo centralizuotos programinės įrangos kūrimo, kur įmonės generalinis direktorius ar produkto vadovas diktuoja funkcijas, Bitcoin remiasi decentralizuotu dalyvių tinklu, kad susitartų dėl pakeitimų. Šis procesas yra tyčinis, lėtas ir stipriai palankus dabartinei padėčiai, siekiant užtikrinti milijardų dolerių vertės saugumą.
Protokolo evoliucija nėra valdoma formalios balsavimo sistemos ar vienos valdžios. Vietoj to, ji veikia per unikalią techninės dokumentacijos, bendražygių peržiūros ir bendruomenės sutarimo kombinaciją. Supratimas, kaip idėja pereina nuo paprastos diskusijos el. pašto sąraše iki globaliai aktyvuoto kodo pakeitimo, atskleidžia Bitcoin tinklo atsparumą. Tai pabrėžia sistemą, sukurtą atspirti užgrobimui bet kokios vienos grupės, nesvarbu, ar tai būtų kūrėjai, kalnakasiai, ar korporaciniai interesai.
Šio evoliucinio proceso šerdyje yra Bitcoin Gerinimo Pasiūlymas, arba BIP. Tai pagrindinis mechanizmas naujoms funkcijoms siūlyti, rinkti bendruomenės nuomones dėl problemos ir dokumentuoti dizaino sprendimus. BIP nėra privalomas balsavimas, o veikiau techninis dizaino dokumentas. Jis teikia informaciją Bitcoin bendruomenei arba aprašo naują funkciją Bitcoin ar jo procesams.
Bitcoin Gerinimo Pasiūlymo sistema
Norint suprasti, kaip keičiasi Bitcoin, pirmiausia reikia suprasti standartizacijos procesą. BIP sistema stipriai įtakota Python Gerinimo Pasiūlymo (PEP) proceso. Ji tarnauja kaip formalus būdas įvesti pakeitimus į kodų bazę ar aplinką. Bet kas gali parašyti BIP, bet jį priimti ir įdiegti – tai griežtas išbandymas, kurį išgyvena nedaug pasiūlymų.
BIP apibrėžimas
BIP iš esmės yra techninis straipsnis. Jis siūlo glaustą funkcijos techninę specifikaciją ir racionalų pagrindimą. Autorius atsakingas už sutarimo kūrimą bendruomenėje ir nesutariančių nuomonių dokumentavimą. Yra trys pagrindiniai BIP tipai. Standartų sekos BIP aprašo bet kokį pakeitimą, kuris paveikia daugumą ar visas Bitcoin įgyvendinimus, pvz., tinklo protokolo pakeitimą ar bloko ar sandorio galiojimo taisyklių pakeitimą.
Informaciniai BIP aprašo Bitcoin dizaino problemą, teikia bendras gaires ar informaciją Bitcoin bendruomenei, bet nesiūlo naujos funkcijos. Procesiniai BIP aprašo procesą, susijusį su Bitcoin, arba siūlo proceso pakeitimą (ar įvykį). Dauguma viešojo dėmesio tenka Standartų sekos BIP, nes tai pasiūlymai, kurie keičia tinklo konsensuso taisykles.
Pasiūlymo gyvavimo ciklas
BIP gyvenimas prasideda gerokai prieš jam priskiriant numerį. Paprastai jis prasideda diskusijomis Bitcoin kūrėjų el. pašto sąraše. Čia pradinis sumanymas yra peržiūrimas, kritikuojamas ir dažnai suplėšomas kitų kūrėjų. Jei idėja išgyvena šį pradinį ugnies išbandymą, autorius parengia BIP tekstą.
Kai juodraštis pateikiamas BIP saugykloje, redaktorius priskiria jam numerį. Ši būsena žinoma kaip „Juodraštis“. Toliau pasiūlymas pereina įvairias stadijas. Jei bendruomenė sutinka, kad darbas vertingas, jis gali pereiti į „Siūlomą“. Jei pakeitimai įdiegti ir tinklas juos aktyvuoja, BIP tampa „Galutinis“ arba „Aktyvus“. Priešingai, pasiūlymai gali būti „Atmesti“, „Atšaukti“ autoriaus ar pažymėti „Pasenęs“, jei juos pakeičia naujesni sprendimai.
Sutarties mechanizmas
Labiausiai klaidinantis Bitcoin kūrimo aspektas išoriniams stebėtojams yra formalios valdymo struktūros nebuvimas. Nėra fondo ar lyderio, kuris patvirtintų BIP žyma „patvirtinta“. Vietoj to, tinklas remiasi koncepcija, vadinama „apytiksliu sutarimu“. Tai terminas, pasiskolintas iš Internetinės inžinerijos darbo grupės (IETF). Tai nereiškia vienodumo.
Apytikslio sutarimo supratimas
Apytikslis sutarimas pasiekiamas, kai techninė bendruomenė apskritai sutinka, kad pasiūlymas patikimas ir kad visi reikšmingi prieštaravimai išspręsti. Tai kokybinis matavimas, o ne kiekybinis balsavimas. Jei pasiūlymas turi stiprų techninį pagrindą, bet susiduria su pagrįstais saugumo rūpesčiais iš reikšmingos kūrėjų dalies, jis nebus tęsiamas.
Ši dinamika verčia autorius bendrauti su kritikais. Jie turi tobulinti pasiūlymus, kol prieštaravimai išspręsti ar įrodyti nepagrįsti. Šis procesas gali užtrukti metus. Pavyzdžiui, Taproot atnaujinimas buvo diskutuojamas ir tobulinamas ištisą laikotarpį prieš laikant jį pasirengusiu aktyvacijai. Lėtumas yra savybė, o ne klaida, neleidžianti skubotų sprendimų, kurie galėtų destabilizuoti finansinį tinklą.
Kūrėjų commit prieigos teisės
Dažnas nesusipratimas yra tai, kad kūrėjai su „commit prieiga“ į Bitcoin Core GitHub saugyklą valdo Bitcoin. Nors šie palaikytojai gali sujungti kodą į pagrindinę programinės įrangos šaką, jie veikia labiau kaip tvarkytojai nei valdovai. Jų vaidmuo – užtikrinti, kad sujungtas kodas atspindėtų bendruomenės apytikslį sutarimą.
Jei palaikytojas sujungtų kodą, kuris fundamentaliai pakeistų Bitcoin prieš naudotojų valią, mazgų operatoriai paprasčiausiai atsisakytų atnaujinti į tą versiją. Tinklas tęstųsi su ankstesne versija, o palaikytojo versija būtų ignoruojama. Tai sukuria galingą kontrolę kūrėjų įtakai, užtikrinant, kad jie liktų atsidavę mazgų tinklo norams.
Aktyvacijos ir įgyvendinimo keliai
Kai protokolo atnaujinimas užkoduotas ir sujungtas į Bitcoin Core programinę įrangą, jis lieka neaktyvus. Jis turi būti „aktyvuotas“ tinklo. Tai stadija, kai teorinis sutarimas sąveikauja su blokų grandinės fizine realybe. Aktyvacija reikalauja koordinacijos tarp sistemos ekonominių dalyvių, pirmiausia kalnakasių ir pilnų mazgų operatorių.
Kalnakasių signalizavimas ir slenksčiai
Istoriniaiškai aktyvacija dažnai naudojo BIP 9 apibrėžtą procesą. Tai apima kalnakasius, signalizuojančius savo pasirengimą atnaujinimui blokų antraštėse, kurias jie kasa. Tam tikrą laikotarpį, paprastai dvi savaites (2016 blokų), tinklas stebi, kiek blokų turi palaikymo signalą atnaujinimui.
Jei signalizuojančių blokų procentas pasiekia apibrėžtą slenkstį – dažnai 90% ar 95% – atnaujinimas užfiksuoja. Po to sekančio malonės laikotarpio naujos taisyklės tampa aktyvios. Šis mechanizmas sukurtas užtikrinti sklandų tinklo atnaujinimą be kalnakasių palikimo. Tačiau jis taip pat sukėlė politinius konfliktus, kur kalnakasiai faktiškai vetavo atnaujinimus atsisakydami signalizuoti, net jei platesnė naudotojų bazė to norėjo.
Naudotojų aktyvuoti minkštieji šakojimai
Kalnakasių signalizavimo ribotumas tapo akivaizdus per „Bloko dydžio karą“ iki 2017 m. Kai kalnakasiai stabdė Segregated Witness (SegWit) aktyvaciją, atsirado žoliapjūvio judėjimas, siūlantis Naudotojų aktyvuotą minkštąjį šakojimą (UASF), žinomą kaip BIP 148.
UASF atveju mazgų operatoriai paleidžia programinę įrangą, kuri atmeta blokus iš kalnakasių, nesignalizuojančių atnaujinimui po tam tikros datos. Tai perkelia galią nuo kalnakasių atgal ekonominei mazgų daugumai. Jei ekonominė veikla (biržos, piniginės, naudotojai) persikels į UASF grandinę, kalnakasiai bus ekonomiškai skatinami sekti arba rizikuoti kasti beverčioje grandinėje. BIP 148 grėsmė buvo lemiama SegWit aktyvacijai priversti.
Šakojimosi dinamika ir suderinamumas
Bitcoin protokolo pakeitimai paprastai patenka į dvi kategorijas: minkštieji šakojimai ir kietieji šakojimai. Skirtumas slypi atgaliniame suderinamume. Skirtumo supratimas yra esminis suprasti, kodėl Bitcoin liko viena nuolatine tinklu nepaisant daugybės atnaujinimų.
Minkštojo šakojimosi mechanizmas
Minkštasis šakojimas yra protokolo pakeitimas, ribojantis galimų blokų rinkinį. Jis griežtina taisykles. Kadangi naujos taisyklės yra senų taisyklių dalis, seni mazgai, neatsinaujinę, vis tiek matys naujus blokus kaip galiojančius. Jie gali nesuprasti naujų funkcijų, bet priims grandinę.
Šis atgalinis suderinamumas yra gyvybiškai svarbus. jis leidžia tinklui atnaujintis palaipsniui. Naudotojai nepriverčiami nedelsiant atnaujinti programinės įrangos, kad liktų konsensuso dalimi. Dauguma pagrindinių atnaujinimų, įskaitant SegWit ir Taproot, buvo įgyvendinti kaip minkštieji šakojimai. Tai užtikrina, kad tinklas nesiskaidytų į dvi nesuderinamas grandines tik todėl, kad kai kurie naudotojai lėtai atnaujinasi.
Kieto šakojimosi išsiskyrimas
Kietasis šakojimas laisvina taisykles ar įveda nesuderinamas su sena programine įranga taisykles. Seni mazgai matys blokus, sukurtus pagal naujas taisykles, kaip negaliojančius ir juos atmes. Kad kietasis šakojimas pavyktų neskeldamas tinklo, 100% naudotojų turi atnaujinti vienu metu, kas neįmanoma decentralizuotoje sistemoje.
Dėl to prieštaringi kietieji šakojimai beveik visada baigiasi nuolatine grandinės skilimu. Žinomiausias pavyzdys yra Bitcoin Cash (BCH) sukūrimas 2017 m. Šalininkai norėjo padidinti bloko dydžio ribą, taisyklės pakeitimas, nesuderinamas su esamu Bitcoin konsensusu. Tai sukėlė dvi skirtingas tinklus ir valiutas. Kietieji šakojimai paprastai vengiami Bitcoin kūrime dėl šios tinklo ir bendruomenės skilimo rizikos.
| Palyginimo atributas | Minkštasis šakojimas | Kietasis šakojimas |
|---|---|---|
| Suderinamumas | Atgalinis suderinamumas | Ne atgalinis suderinamumas |
| Taisyklių pakeitimas | Griežtina/riboja taisykles | Laisvina/plėtoja taisykles |
| Tinklo rizika | Maža grandinės skilimo rizika | Didelė nuolatinio skilimo rizika |
Pagrindiniai protokolo atnaujinimai: Segregated Witness
Vienas reikšmingiausių pasiūlymo įgyvendinimo pavyzdžių yra Segregated Witness (SegWit). Aktyvuotas 2017 m. rugpjūtį, jis išsprendė ilgalaikes problemas ir paruošė pagrindą ateities mastelio keitimui. Pasiūlymas fundamentaliai pakeitė sandorio duomenų struktūrą.
Malleability sprendimas
Prieš SegWit buvo įmanoma modifikuoti unikalią sandorio ID prieš jam patvirtinant blokų grandinėje, neinvalidinant parašo. Ši problema, žinoma kaip sandorio malleability, trukdė kurti antro lygio sprendimus, pvz., Lightning Network. Jei sandorio ID galėjo keistis, protingos sutartys, remiančios tą ID, sugestų.
SegWit tai išsprendė perkeldamas parašo (liudytojo) duomenis už sandorio dalies, naudojamos ID skaičiavimui. Atskiriant liudytoją, sandorio ID tapo nekeičiamas. Šis taisymas buvo pagrindas, leidžiantis mokėjimo kanalams veikti saugiai ir skatinantis Lightning Network kūrimą.
Svorio vieneto koncepcija
SegWit taip pat veikė kaip gudrus bloko dydžio padidinimas. Užuot tiesiog pakėlęs 1 MB ribą – kas būtų reikalavęs kieto šakojimo – SegWit pakeitė, kaip matuojami blokai. Jis įvedė „bloko svorį“.
Duomenys liudytojo sekcijoje skaičiuojami mažesniu svoriu nei pagrindinio sandorio bloko duomenys. Tai leidžia blokams viršyti tradicinį 1 MB dydį žaliųjų duomenų atžvilgiu (teoriškai iki 4 MB), likant suderinamiems su senais mazgais, tikrinančiais tik ne-liudytojo duomenis. Tai efektyviai padidino tinklo talpą ir sumažino mokesčius sandoriams SegWit formatu.
Taproot atnaujinimas
Po SegWit kitas pagrindinis pakeitimas buvo Taproot, aktyvuotas 2021 m. lapkritį. Taproot sujungė tris BIP (340, 341 ir 342), kad pagerintų privatumą, efektyvumą ir scenarijų galimybes. Jis demonstravo rafinuotesnį aktyvacijos procesą, vadinamą „Speedy Trial“.
Schnorr parašai
Taproot šerdyje yra Schnorr parašų (BIP 340) įgyvendinimas. Ši skaitmeninio parašo schema siūlo reikšmingus pranašumus prieš originalų Elliptic Curve Digital Signature Algorithm (ECDSA). Pagrindinė nauda yra liniškumas.
Liniškumas leidžia parašų agregavimą. Daugiasignatarių sandoryje keli viešieji raktai ir parašai gali būti sujungti į vieną raktą ir vieną parašą. Blokų grandinei sudėtingas sandoris su daugybe šalių atrodo identiškai kaip standartinis vieno naudotojo sandoris. Tai pagerina privatumą maskuodamas piniginės išdėstymo sudėtingumą ir taupo vietą blokų grandinėje, mažindamas mokesčius.
Merkelized Abstract Syntax Trees
Taproot taip pat įvedė Merkelized Abstract Syntax Trees (MAST). Anksčiau, jei naudotojas sukurdavo sudėtingą protingą sutartį su daugybe išleidimo sąlygų, visos tos sąlygos turėdavo būti atskleistos blokų grandinėje, kai lėšos išleidžiamos. Tai buvo neefektyvu ir blogai privatumui.
Su MAST naudotojai gali struktūrizuoti išleidimo sąlygas medžio formatu. Išleidžiant, jie turi atskleisti tik konkrečią medžio šaką, kuri naudojama. Neįvykdytos šakos lieka paslėptos. Tai leidžia sudėtingas protingas sutartis, kurios yra privačios ir duomenų efektyvios, dar labiau plėtodamos Bitcoin potencialą už paprasto vertės perkėlimo ribų.
Dabartiniai debatai: OP_CAT atvejis
Bitcoin evoliucija vyksta toliau, su dabartinėmis diskusijomis, orientuotomis į prarastos funkcionalumo atkūrimą. Vienas ryškiausių temų yra OP_CAT. Tai specifinis opcode (operacijos kodas), kuris buvo originalios Bitcoin programinės įrangos dalis, bet buvo išjungtas Satoshi Nakamoto 2010 m. dėl atminties naudojimo ir saugumo pažeidžiamumų rūpesčių.
Opcode supratimas
Opcode yra komandos, kurias supranta Bitcoin scenarijų kalba. Jos nurodo tinklui, kaip apdoroti sandorį. Kai kurie opcode leidžia sudėjimą, kiti tikrina parašus, kai kurie patikrina laiko užraktus. Kai opcode išjungiami, galimybė atlikti tas specifines operacijas pašalinama iš tinklo įrankių dėžutės.
OP_CAT ir kitų pašalinimas stipriai apribojo Bitcoin scenarijų kalbą. Šis apribojimas buvo tyčinis tuo metu, prioritetizuojant saugumą ir stabilumą prieš funkcionalumą. Tačiau, protokolo supratimui subrendus, kūrėjai dabar tyrinėja saugų šių kodų reintegravimą, kad įgalintų naujas funkcijas.
Jungimo pasiūlymas
OP_CAT konkrečiai leidžia dviejų duomenų eilučių sujungimą (concatenation). Nors tai skamba paprastai, tai įgalina galingą funkciją, vadinamą „covenants“. Covenants leidžia naudotojams nustatyti apribojimus, kaip ateityje bitkoinai gali būti išleidžiami, ne tik kam juos galima išleisti.
Pavyzdžiui, covenant galėtų priversti, kad specifinis UTXO galėtų būti siunčiamas tik į specifinį leidžiamų adresų sąrašą. Tai turi didžiulę įtaką seifų mechanizmams, kur naudotojai galėtų sukurti „atšaukimo“ mygtukus pavogtoms lėšoms, ir Layer 2 tiltams. Debatai aplink OP_CAT iliustruoja Bitcoin kūrimo konservatyvumą; net paprasta komanda reikalauja metų saugumo analizės prieš reintegravimą.
Įtaka Layer 2 sprendimams
Protokolo pasiūlymai dažnai taikomi baziniam sluoksniui, bet jų pagrindinė nauda realizuojama Layer 2 (L2) tinkluose. Pagrindinės blokų grandinės ir šių antrinių sluoksnių santykis yra simbiotinis. Bazinio protokolo patobulinimai daro L2 pigesnius, saugesnius ir efektyvesnius.
Lightning Network priklausomybės
Lightning Network yra puikus šios priklausomybės pavyzdys. Jis remiasi bazinio sluoksnio saugumu sandoriams galutinai įforminti. Kaip minėta, SegWit atnaujinimas buvo Lightning patikimai veikimui būtinas. Ateities atnaujinimai toliau taikosi į Lightning efektyvumą.
Pavyzdžiui, pasiūlymai kaip „Eltoo“ (SIGHASH_ANYPREVOUT) siekia supaprastinti kanalų valdymą. Modifikuodami, kaip sandoriai pasirašomi baziniame sluoksnyje, Lightning mazgai gali saugoti mažiau duomenų ir lengviau atsigauti iš gedimų. Tai rodo, kaip L1 pasiūlymai dažnai varomi L2 mastelio poreikių.
Šoninių grandinių integracija
Šoninės grandinės, tokios kaip Liquid ar Rootstock, taip pat gauna naudos iš protokolo atnaujinimų. Šoninės grandinės yra nepriklausomos blokų grandinės, veikiantis lygiagrečiai su Bitcoin. Jos naudoja dvikryptį pegą vertei perkelti pirmyn atgal. Šiuo metu šie pegai dažnai remiasi federacijomis – patikimų vykdytojų grupėmis.
Atnaujinimai kaip OP_CAT ar naujos parašo schemos galėtų leisti labiau be-pasitikėjimo tiltų mechanizmus. Jei Bitcoin scenarijus gali patikrinti įrodymus iš šoninės grandinės (kaip Zero-Knowledge įrodymus), tai leistų naudotojams perkelti lėšas tarp grandinių be federacijos pasitikėjimo. Tai lieka pagrindine tyrimų ir naujų BIP motyvacijos sritimi.
Nenuspėjama inovacija: Ordinals fenomenas
Kartais protokolo atnaujinimai veda prie visiškai netikėtų rezultatų. Ordinals kilimas yra atviro kodo programinės įrangos netiesioginių pasekmių įstatymo liudijimas. Ordinals naudoja SegWit ir Taproot mechanikas duomenims įrašyti tiesiogiai ant individualių satoshi.
SegWit padarė pigesnį liudytojo duomenų saugojimą, o Taproot pašalino duomenų stūmimo dydžio ribą sandorio scenarijuose. Sujungus, šie pakeitimai leido naudotojams įterpti vaizdus, tekstą ir net video žaidimus į Bitcoin blokų grandinę. Tai nebuvo specifinis tų BIP autorių ketinimas.
Šis vystymasis sukėlė aršias debatus bendruomenėje. Kai kurie laiko įrašus spamu, užkemšančiu tinklą, kiti mato kaip teisėtą bloko erdvės naudojimą, apmokamą mokesčiais. Nepaisant požiūrio, Ordinals demonstruoja, kad įdiegus pasiūlymą, tinklo naudotojai naudos naujas taisykles būdais, kurių autoriai galbūt niekada nebuvo numatę.
Išvada
Bitcoin protokolo pasiūlymo anatomija atskleidžia sistemą, kuri prioritetizuoja išlikimą virš viso kito. Nuo pradinio BIP juodraščio iki varginančio apytikslio sutarimo kūrimo proceso, kiekvienas žingsnis sukurtas filtruoti rizikas. Skirtumas tarp minkštųjų ir kietųjų šakojimų iliustruoja įsipareigojimą atgaliniam suderinamumui, užtikrinantį, kad tinklas liktų įtraukiantis netgi tobulėdamas.
Atnaujinimai kaip SegWit ir Taproot rodo, kad Bitcoin gali inovuoti neaukodamas pagrindinių principų. Tuo tarpu, besitęsiantys debatai aplink OP_CAT ir Ordinals atsiradimas įrodo, kad ekosistema lieka gyvybinga ir nenuspėjama. Sąveika tarp kalnakasių, kūrėjų ir mazgų operatorių kuria patikrinimų ir pusiausvyrų sistemą, kurios jokia centralizuota institucija negali paneigti.
Bitcoin keičiasi lėtai ne todėl, kad negali greitai judėti, bet todėl, kad jį sulaužyti kainuoja per daug didelę riziką.