Ahogyan a neve is utal rá, a Bitcoin Improvement Proposal (BIP, lefordítva: Bitcoin-fejlesztési javaslat) egy olyan szabvány, melyet a BTC-k alapprotokolljának megváltoztatására, módosítására fejlesztettek ki, de néhány esetben kulcsfontosságú információforrásként is szolgál a Bitcoin (BTC) közösségek számára.
Mi az a BIP, és hogyan működik?
A BIP-ek tartalmazhatnak konszenzus alapján kritikus változtatásokat (mint a például a softfork és a hardfork protokollfrissítések), de más változtatásokat is, melyek előnyt kovácsolnak a különböző Bitcoin szoftver-impletmentációk közötti koordinációból, például a peer-to peer réteg változtatása vagy új backup seed formátumok.
Azonban fontos leszögezni, hogy nem minden Bitcoin szoftver implementációt érintő változtatás befolyásolja a Bitcoin protokollt. Például néhány módosítás csak hatékonyabbá teszi a kód futtatását, vagy megváltoztatja a felhasználói felületet, ezek az ún. információs BIP-ek. Az ehhez hasonló független fejlesztők által végrehajtott rutinszerű változásokhoz nincs szükség a BIP nagyközösség általi elfogadására.
Blockchain Fork, softfork, hardfork
A Bitcoin fork egy folyamat, a blokkchain, azaz a blokklánc elágaztatása az eredeti verziótól a forráskód megváltoztatásával. Egy fork akkor jelenik meg, amikor a blokklánc kettéválik. Ez lehet a megosztás konszenzusban vagy a protokoll alapjául szolgáló szabályokban történő változás miatt. Mivel a Bitcoin nyílt forráskódú, ezért szabadon forkolható a paraméterek megváltoztatásával.
Megosztás
A Bitcoin egy konszenzusra épülő hálózat. A fork kialakulhat, amikor a bányászok egyszerre fedeznek fel egy blokkot és az kettéválik. Ez azonban egy ideiglenes fork, mivel az a lánc, amely először megtalálja a következő blokkot a leghosszabb lánccá és automatikusan igazzá válik. Ezért a rövidebb láncot elhagyja a hálózat.
Változás a protokoll alapjául szolgáló szabályokban
Ez a kódok tudatos megváltoztatását jelenti fejlesztők által, ezek végleges forkok. A codebase megváltoztatásának okai a következők lehetnek:
- Új funkciók hozzáadása a hálózat funkcionalitásának javítása érdekében
- Alapszabály megváltoztatása (például a blokk méretének növelése)
Mivel az első kategóriában (megosztás konszenzusban) előforduló forkok ideiglenesek, amikor valaki forkokról beszél, a fókusz a protokoll alapjául szolgáló szabályok változtatásán van. Az ebbe a kategóriába tartozó forkok állandó jellegűek és a hálózat résztvevőitől megkövetelik, hogy frissítsék Bitcoin szoftvert, integrálják az új változásokat a jelenlegi szoftverükbe.
A protokoll alapjául szolgáló szabályok változásának leggyakoribb kategóriái: softforkok és hardforkok.
Softfork
A softfork olyan szoftverfrissítés, amely visszafelé kompatibilis a régebbi verziókkal. Ez azt jelenti, hogy azok a résztvevők, akik nem frissítettek az új szoftverre, továbbra is részt vehetnek a tranzakciók érvényesítésében és ellenőrzésében. Példa a softforkra, amikor az új szabály kimondja, hogy a blokk mérete a jelenlegi 1 MB-ról (1000KB) 800 KB-ra változik.
Sokkal könnyebb egy sorftforkot megvalósítani, mint a hardforkot, mivel a résztvevők csak több, mint felének kell frissítenie a szoftvert, hogy átmenjen a javaslat. Függetlenül attól, hogy frissített-e vagy sem, minden közreműködő továbbra is felismeri az új blokkokat és fenntartja a kompatibilitást a hálózattal.
Azonban megjegyzendő, hogy a nem frissített résztvevő funkcionalitása érintett. Habár továbbra is látni fogják, hogy a bejövő új tranzakciók érvényesek, amikor új blokkokat próbálnak kibányászni, blokkjaikat – és így erőfeszítéseket – a hálózat elutasítja.
A sortforkok ezért fokozatos frissítési mechanizmust képviselnek, mivel azokat, akik még nem frissítették szoftvert, ösztönzik erre, vagy egyéb esetben fennáll a veszélye, hogy csökken a funkcionalitásuk.
Softfork példák:
- BIP 66: A Bitcoin aláírás-hitelesítésének softforkja.
- P2SH (Pay-to-Script-Hash): Egy softfork, amely megváltoztatta a Bitcoin hálózatban a címke formázást.
Hardfork
A hardfork a szoftverfrissítés olyan típusa, amelyek nem kompatibilisek a régebbi verziókkal. Minden résztvevőnek frissítenie kell az új szoftverre a további részvételhez és az új tranzakciók érvényesítéséhez.
Azok, akik nem frissítettek, le lesznek választva a hálózattól és nem tudják érvényesíteni az új tranzakciókat. Ez a szétválás a blokklánc örökös elágazását eredményezi.
Amíg van támogatás a kisebbségi láncban – a láncban bányászó résztvevők formájában -, a két lánc egyidejűleg létezik.
Összességében a hardforkok a kriptovaluta kikerülhetetlen szempontjai. Némelyikük törvényes, míg mások egyenesen átverések. A hardforkokat körülvevő összes vita ellenére, a forkoknak feltétlenül előnyei vannak a kripto közösség irányában.
A hardfork legfontosabb példája az Ethereum.
BIP – a kezdetek
Ha a Bitcoin Improvement Proposal létrejöttének történetét vesszük, az első ilyen javaslatot először a korai kriptofejlesztő, Amir Taaki fejlesztette ki, aki széles körben ismert lett azáltal, hogy megalkotta a Bitcoin protokoll első alternatív implementációját: a Libbitcoin-ot. Taaki a blogjában leírta, hogy a BIP-ek – megfelelően használva – a Bitcoin fejlesztési folyamatára nézve hatalmas potenciált hordoznak: strukturáltabbá és átláthatóbbá téve a kriptovaluta természetes ökoszisztémáját.
Taaki 2011. augusztusában nyújtotta be az első BIP-et (0001) a Bitcoin nagyközönségnek, amely leírta magát a BIP-folyamatot. A dokumentum lényegében rávilágított arra, hogyan kell a BIP-eket körülvevő teljes folyamatot lebonyolítani. Javarészt az a folyamat ihlette, amelyet jelenleg a Python programozási nyelvhez társított apróságok javítására használnak (amint azt a PEP0 – Python Enhancement 0. javaslat – leírja).
Hogyan lesz elfogadva / elutasítva a BIP?
Mint bármely javaslat általában, a BIP is egy vázlatként indul, amelyet egy vagy több szerző nyújt be. Ezt megelőzően azonban, még a benyújtás előtt, a BIP tervezet mindig hosszasan meg van vitatva informálisan a BTC fejlesztői levelezőlistán, az Internet Relay Chat (IRC) csatornán vagy más egyéb platformokon. Tervezetként a BIP akárhányszor módosítható és javítható a szerző(k) által, közösségi visszajelzések alapján. A Bitcoin protokollváltozások esetén referencia-megvalósítást is igényel, kódban. Ha a javaslat eléri a közösségi konszenzust, akkor tekintik azt véglegesnek.
Az alábbi képen látható a BIP folyamat a 0001 BIP alapján.
Kép forrása: GitHub
Az elfogadás végső soron akkor történik, amikor a fejlesztők implementálják a kódot, ami reflektál a BIP-re és a felhasználók úgy döntenek, hogy letöltik és futtatják ezt a kódot.
BIP életciklus
A BIP típusától függően válhat szükségessé a közösség konszenzusa ahhoz, hogy a javaslat átmenjen. Mielőtt azonban a dolgok eljutnának erre a szintre, a BIP-nek számos szakaszon keresztül kell mennie, úgy mint:
- tervezet,
- igazolás,
- közösségi elfogadás,
- elfogadás / elutasítás vagy módosítás.
Mit jelentenek a BIP számok?
BIP számokat a BIP szerkesztő határozza meg. A jelenlegi BIP szerkesztő a Bitcoin Core közreműködője és a Bitcoin Knots fenntartója, Luke-Jr. A BIP-ek számozása megtörténik, amint a tervezet megfelel a minimális formázási követelményeknek, valamint a javaslat teljes egésznek tekintett. A BIP szerkesztő bizonyos tartományokat fenntarthat a közös témájú javaslatokra. De igazából, a számozás nem számít.
BIP típusai
A Bitcoin Improvement Proposal három fő típusa: Standards Track BIP, Informational BIP, Process BIP. Ezekkel a típusokkal érdemes tisztában lenni, ezért egy kicsit bővebben ezekről:
Standard BIP
Ezek olyan javaslatok, melyek célja a BTC hálózati protokolljának megváltoztatása, az adatok blokkolása vagy akár az ökoszisztéma natív tranzakcióinak érvényesítése. Ez a típus a BIP két változatának interoperabilitását (együttműködésére való képességét) is megváltoztathatja, ezért a közösség konszenzusa szükséges az életbe lépéséhez.
Informational BIP
Az információs előterjesztések célja különféle design kérdések, általános irányelvek és más ehhez hasonló adatok, mellyel a közösség nagy egészének nem igazán kell komolyan foglalkoznia.
- Process BIP
Az ilyen fejlesztési javaslatok a Bitcoin ökoszisztéma alapvető folyamataink megváltoztatására törekszenek.
Néhány híres BIP példa
- BIP
A BIP 141 javaslatot (ismertebb nevén SegWit – Segregated Witness vagyis elválasztott hitelesítés) 2015-ben vezetett be néhány fejlesztő, akik akkoriban a Bitcoin Core projekten dolgoztak. A BIP 141 arra hivatott, hogy a tranzakciókat az aláírások ellenőrzésének nagyobb hatékonyságával gyorsítsa. növelje a BTC natív hálózatának mérhetőségét, valamint számos kérdést megoldjon a valuta tranzakciós teljesítményével kapcsolatban. Ezenkívül meg kell említeni, hogy a javaslatot soft fork fejlesztésen keresztül hajtották végre, a bányászok több, mint 95% -a beegyezett a frissítésbe.
Röviden összefoglalva a SegWit célja, hogy növelje a BTC hálózat kapacitását, lehetővé tegyen több tranzakciót egyes BTC blokkokon belül.
- BIP
A BIP 141-hez hasonlóan a BIP 91 is egy soft fork javaslat volt még 2017 közepén, Bitmain James Hilliard nevéhez köthető. A BIP 91 célja a meglévő SegWit megoldás (azaz a BIP 141) aktiválása volt a tranzakciók végrehajtásának gyorsításával, a blokkméret növelésével.
Kötelező, vagy sem?
Végső soron a fejlesztők döntenek arról, hogy milyen kódot használnak és mindenkinek a saját választása, hogy melyik szoftvert futtatja a számítógépén, sőt, az is, hogy melyik szoftvert és protokollt tekinti BTC-nek. A BIP nem kötelező, csupán egy javaslat, de azért méri fontolóra venni és tiszteletben kell tartanunk a közösségnek az ilyen projektek kidolgozásához való jogát, ha összhangban akarunk maradni a decentralizáció és a nyílt forráskód elveivel, mert így adta ki Satoshi is a Bitcoin kódot.
Felhasznált források:
- Bitcoin Wiki: https://en.bitcoin.it/wiki/Main_Page
- Bitcoin Improvement Proposal: https://en.bitcoinwiki.org/wiki/Bitcoin_Improvement_Proposals
- What is a BIP (Bitcoin Improvement Proposal)? Why do you need to know about it?: https://coinsutra.com/bip-bitcoin-improvement-proposa/
- BIP folyamat: https://en.bitcoin.it/wiki/BIP_0001
- BIP 141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
- BIP 91: https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
