Milyen előnyökkel jár a Taproot frissítés a hardvertárcák használóinak?
A Taproot frissítés november közepén aktiválódott a Bitcoin mainnet hálózatán. A nem technikai Bitcoin rajongók számára nem könnyű megérteni, hogy mit is hozott ez az technológiai implementáció. De ez csak akkor van így, ha arra összpontosítunk, hogy mi az, és hogyan működik technikai szinten, azaz ha túlságosan a „mit” és a „hogyan”-ra összpontosítunk a különféle Bitcoin-elemeknél, miközben figyelmen kívül hagyjuk a „miért”-et. Azaz hogy miért kellett ezt végrehajtani a Taproot upgradet?
A miértre az egyszerű válasz, hogy jobb Bitcoint kapunk általa. A Taproot segítségével ugyanis új lehetőségek nyílnak meg a Bitcoin számára, olyanok mint a Lightning Network csatornakezelés vagy a multisig-ek hatékonyabbak, privátabbak és egyszerűbbek. A jövőben csak az emberek kisebb része fogja tartani a saját coinjait az alaprétegen; a fennmaradó milliárdokhoz megbízható második (sőt talán harmadik vagy negyedik) rétegre lesz szükség az alapréteg felett/mellett. A Taproot fontos lépés e jövő felé, mivel minden eddiginél hozzáférhetőbbé teszi a Bitcoin rétegekre épülő fejlődését. A különféle Bitcoin-eszközöket fejlesztők és gyártók pedig felelősek azért, hogy mindenfajta késedelem nélkül megvalósítsák azokat az eszközöket, amik a Bitcoin hálózat hosszú távú fejlesztés katalizátoraival, mint például a Taproot frissítéssel is kompatibilisek.
A mai cikkünkben a Taproot frissítés hatásait összegezzük a hardvertárca gyártók szempontjából.
A Taproot új címtípust vezetett be
Az első fontos elem a tárca felhasználók számára, hogy a Taproot új címtípusokat vezet be. Az eredeti SegWit (SegWit v0, bech32 kódolású) címek „bc1q”-vel kezdődtek, míg a Taproot címek (SegWit v1, bech32m kódolású) „bc1p”-t tartalmaznak. Ez elsőre technikai jellegűnek tűnhet. De tény, hogy a Taproot címeket nem fogják automatikusan támogatni azok a tárcák és szolgáltatások, amelyek jelenleg csak az eredeti SegWit-et támogatják. A tárcamegoldások fejlesztőinek, a kriptotőzsdéknek és más szolgáltatóknak is be kell vezetniük az új címtípust, ahogyan a SegWit v0 esetében is tették jó pár évvel korábban. A főbb kriptotőzsdék és tárcák kompatibilitásának jelenlegi állapota megtalálható a Bitcoin Wiki-n (a Bech32m és a P2TR támogatását jelző oszlopok a Taprootra vonatkoznak).
Érdekes tény, hogy a Taproot címek hossza 62 karakter, míg a SegWit cím csak 42 karakter volt (az „1”-el vagy „3-mal” kezdődő régi címek 34 karakterből álltak).
A Trezor míg idén, decemberében be fogja vezetni a Taproot címek támogatását. Ez azt jelenti, hogy miután a felhasználó letölti az új firmware-t, az új címtípus megjelenik a fióktípus kiválasztásában. Természetesen a felhasználóknak nem kötelező a Taproot címtípust használni, mivel az összes korábbi címtípus is korlátlan ideig támogatott lesz még.
Kompatibilitás
Az új címtípussal együtt jár a kompatibilitás okozta probléma is. Amikor 2017-ben az első tárcák bevezették az eredeti SegWit-et, az új címtípus érvénytelen volt a legtöbb tárcánál és kriptotőzsdénél. Ugyanis sok tárcafejlesztő és szolgáltató csak lassan állt át az új címtípusra. Ez a tipikus melyik volt előbb, a tyúk vagy tojás probléma. A felhasználók nem tudják használni, mert a fejlesztők még nem implementálták. A gyártók meg nem vezetik be, mert még nincs elég felhasználó. Ez a gordiuszi csomó csak akkor oldható fel, ha a fejlesztők proaktívan implementálják az új funkciót, amely végső soron az egész Bitcoin ökoszisztéma javára válik.
Két évbe telt, mire a SegWitet az összes Bitcoin-tranzakció legalább felében használni kezdték, annak ellenére, hogy nem volt semmilyen hátránya a használatának. Sőt, a felhasználók számára a tranzakciós díjak is alacsonyabbak voltak a SegWit esetében, mégis két évre volt szükség a nagyobb adaptációig. Nagyon valószínű, hogy több évbe telhet most is, amíg a Taproot címeket is széles körben kezdik el használni.
A Taproot tranzakciók alacsonyabb költségekkel végrehajthatóak
A SegWithez hasonlóan a Taproot tranzakciók is csökkentik a tranzakciós súlyt, ami egyúttal olcsóbb díjakat jelent. Ez azonban csak a Taproot címről történő költésnél van így. A Taproot-címre történő küldés drágább lehet, mint a SegWit-címre történő küldés. Alább láthatók a tranzakciós elemek releváns méretei:
- SegWit: publikus kulcs küldés hash = 20 byte; ECDSA aláírás = lehet akár 72 byte is
- Taproot: publikus kulcs küldés hash = 32 bytes; Schnorr aláírás = 64 byte
A Taproot-tal kapcsolatos díjmegtakarítás mértéke erősen függ attól, hogy a felhasználó milyen típusú tranzakciókat kíván végrehajtani a Taproot-címekről. Az alapvető tranzakcióknál (pl. 1 bemenet, 2 kimenet, bonyolult költési feltételek nélkül) nincs megtakarítás – sőt, a felhasználók akár valamivel többet is fizethetnek a Taproot miatt. De a sok inputot és összetett költési feltételeket igénylő bonyolult tranzakcióknál a tranzakciós súly a felére is csökkenhet a nem Taproot alternatívához képest, és az ebből eredő díjmegtakarítás jelentős.
Vagyis a Taproot coinok költése ugyan olcsóbb díjakat hoz, de a megtakarítást leginkább az összetett költési kondíciós struktúrák kezelésekor lehet majd kiaknázni. Ezzel együtt megnyílik a lehetőség a fejlett tranzakciótípusok számára is, amelyek eddig mérhetetlenül drágák lettek volna.
A Taproot nagyobb védelmet is kínál
A Taproot fő előnye a privát adatok védelme területén a tranzakciótípusok lehetséges obfuszkációjából származik. Ennek köszönhetően az olyan fejlett tranzakciók, mint a Lightning Network csatorna megnyitása/bezárása vagy a multisig tranzakciók megkülönböztethetetlenné válhatnak az egyszerű költésektől. Azonban miért csak potenciálisak ezek az előnyök? Egyszerűen azért, mert ezek learatásához a Taproot-tranzakcióknak széles körben elterjedteknek kell lenniük – ami, ahogyan már leírtuk, valószínűleg évekbe fog telni.
A Taproot jövőbeli verzióiban (igen, valószínűleg jönnek újabb frissítéseket) a privát adatok védelme még jelentősebb lehet. A Schnorr-aláírások lehetővé teszik az úgynevezett kereszt input aláírás-összesítést (CISA – cross-input signature aggregation), ahol több, egymástól független tárcából készült aláírások egyetlen aláírásba aggregálhatók. Ez elsősorban a CoinJoin tranzakciókra vonatkozik (a Trezor 2022-ben fogja implementálni a CoinJoint a Suite felületen). A CoinJoin tranzakció végül még olcsóbb is lehet, mint egy egyszerű költés. Azonban fontos kiemelni, hogy ez még most nem lehetséges a jelenlegi Taproot implementációval.
Egyéb előnyök, amit a Taproot hozott el
A Taproot frissítés kijavít egy régóta fennálló elméleti díjcsalás támadástípust is, ahol a tárca használóját olyan tranzakciók küldésére csalhatják, amely túlzott mértékű tranzakciós díj miatt kimerítené a felhasználó számláját. Ez a támadástípus több bemenetes tranzakciókat célozhat meg, ahol a támadó kihasználhatja azt a tényt, hogy a SegWit v0 alatt minden bemenet csak a saját bemeneti mennyiségéhez kötődik. A habár ehhez a támadástípushoz köthető hiányosságot már a főbb hardvertárcákban javították, ez még ma is sok fejtörést okoz néhány projektnek. Még ma is vannak olyan tárcák, ahol ez a sérülékenység még most is meglehet. A SegWit v1 végleg megoldja ezt a problémát, mivel minden bemenet nem csak a saját mennyiségére kötelezi el magát, hanem más bemenetek mennyiségére is. Így most már lehetetlen speciális hamis bemeneteket létrehozni, amelyek a támadás végrehajtásához szükségesek.
Végezetül a hardvertárca felhasználói számára a másik nagy előny az egyszerűsített tranzakció-aláírási és küldési folyamat, különösen akkor, ha nagyszámú tranzakciós bemenetről van szó. A Taproot segítségével a tárcának többé nem kell elküldenie a tranzakciók gyakran kiterjedt történetét, amely megelőzte a költést. Bár az egyszerű költést végző felhasználók nem feltétlenül veszik észre ezt az előnyt, ugyanis ez különösen a CoinJoin tranzakcióknál segít. A tranzakciós előzmények streamelésének szükségessége a Taproot frissítés előtt a CoinJoins esetében nem volt praktikus opció a hardvertárcák számára. Ez most megváltozik, és a felhasználók hamarosan élvezhetik a megnövelt tranzakciós védelmet, amelyet a CoinJoins biztosít majd a hardvertárca tranzakciókhoz is.