A következő poszt elképzelhető, hogy kicsit „Aprópénz az elmém”, azaz „Change my mind” jellegű lesz sokaknak, már, ami a nyelvezetét illeti, ezért felkértem Szegő Dani Barátomat, hogy kicsit lektorálja a posztot, hogy közérthetőbb legyen. Ő meg is tette ezt, volt pár javaslata, köztük az is, hogy a „szövetség” szó helyett használjam a „megállapodás” szót, amit a – cím kivételével – meg is teszek. Jöjjön akkor a poszt.

Előzetesen tisztázni kell az ún. operációs kód fogalmát. Az opkódok (műveleti kódok) a Bitcoin szkriptnyelvének, a Scriptnek lényeges részét képezik, lehetővé téve a műveleteket a Bitcoin hálózaton.

Az opkódok olyan utasítások, amelyek lehetővé teszik a tranzakciós feltételek beállítását a Bitcoin protokollon, és mindegyik műveleti kódot egy adott parancs végrehajtására terveztek a hálózaton.

A Bitcoin programozási nyelve, a Bitcoin Script lehetővé teszi az emberek számára, hogy opkódokat használjanak különböző műveletek végrehajtására. A Bitcoin Script egy egyszerű programozási nyelv, amelyet arra terveztek, hogy korlátozza funkcionalitását, és megakadályozza a hibavégrehajtást és a végtelen hurkok képződést. Azaz segít abban, hogy a bonyolult műveletek ne lassítsák le a hálózatot.

Az opkódok jelentik a Bitcoin szkriptelési képességeinek alapját, amelyek lehetővé teszik az automatizált, testreszabható tranzakciókat. A felhasználók beírhatják a kódot szóparancsként az „OP” előtaggal.

Digitális valutaként a Bitcoin programozható pénz, és az opkódok segítségével különféle parancsokat programozhatunk. A Bitcoin szerkezete lehetővé teszi a felhasználók számára, hogy akár 256 műveleti kódot definiáljanak, amelyekhez 0 és 255 közötti szám van hozzárendelve. Jelenleg ezeknek kevesebb mint fele aktív.

Ugyan a Bitcoin nem arról híres, hogy képes intelligens szerződéseket és tetszőleges szkripteket futtatni, de azt lehetővé teszi, hogy bonyolult költési feltételek mellett történjen meg egy Bitcoin-tranzakció.

Minden Bitcoin cím tartalmaz ugyanis egy sor költési feltételt. Ezek közül a legegyszerűbb az, hogy „a tranzakció feladója birtokolja-e az ehhez a címhez tartozó privát kulcsot”. Vannak más költési feltételek is, például az időzár, amely csak bizonyos idő elteltével engedélyezi a költést – vagy a multisig, amely több privát kulcshoz való hozzáférést igényel egy tranzakció elköltéséhez.

Noha a költési feltételek manapság már elég erőteljesek lehetnek, lényegében mindegyik ugyanazt csinálja: ha a költési feltétel teljesül, a bitcoint a küldő által választott módon el lehet költeni.

Az ún. megállapodás vagy szövetség (covenant) avagy konszenzus kód, olyan költési feltétel, amely új lehetőségeket (azaz további korlátozásokat) vezet be a Bitcoin-tranzakciók elköltésének módjait illetően, azaz a a meglévő Bitcoin szkripteket „fejleszti” tovább, azzal például, hogy korlátozza az UTXO „elköltését”.

A felhasználó csak előre meghatározott szabályok szerint hajthat végre tranzakciókat, ezzel segítve bizonyos üzleti megállapodásokat.

Egyszerű példaként egy Bitcoin-cím tartalmazhat olyan megállapodást, azaz (konszenzus) kódot, amely csak a bitcoin egy másik, előre meghatározott címre történő elküldését teszi lehetővé. Azt is korlátozhatja, hogy mely UTXO-k költhetők el erről a bitcoin címről.

A Bitcoin kontextusában a megállapodás leghasznosabb definíciója az, amikor az UTXO scriptPubKey-je korlátozza a scriptPubKey-t az UTXO-ra fordított tx-költés kimenetében. (forrás: Anthony Towns)

A megállapodás tehát általában csak a szkriptek engedélyezési listáján szereplő készletre engedi meg a költést, például a bitcoinok visszajuttatását a felhasználó saját egyenlegére vagy egy olyan címre történő költést, amely csak egy idő után teszi lehetővé a tetszőleges címre történő költést.

Nézzünk meg most egy olyan javaslatot, amelynek célja ennek a funkciónak az engedélyezése:

Sablon ellenőrzése (OP_ CTV: Check Template Verify).

A CTV egy javaslat a megállapodások bevezetésére a Bitcoin-szkriptbe. Lehetővé teszi a költési feltételek ellenőrzését, azaz hogy a tranzakciós adatok egyeznek-e a megállapodásban meghatározottakkal? Ezt úgy teszi, hogy kivonatolja a tranzakciós adatok egy részét, és összehasonlítja azokat a szerződésben előre meghatározott hash értékekkel.

Mivel ez a tranzakció-kivonat csak a bemenetek, a kimenetek, a verzió és a zárolási idő felhasználásával kerül kiszámításra, ezek előre kiszámíthatók. A CTV megállapodással a Bitcoin-cím kötelezettséget vállal arra, hogy a jövőben csak az előre kiszámított tranzakciókat küldi el.

Ez azt jelenti, hogy mielőtt tranzakciókat fogadna ezen a Bitcoin-címen, pontosan tudnia kell, hogyan fogja ezeket elkölteni. Ez egyaránt tud előnyökkel (de hátrányokkal is) járni. Van aki az egyiket nézni, mások pedig a másikat látják.

Rekurzív megállapodások

A rekurzív megállapodás olyan költési feltétel, amely megköveteli, hogy a következő fogadó címnek is tartalmaznia kell ezt a költési feltételt. Példa erre az egyesült államokbeli háztulajdonosok egyesületei, amelyek megkövetelik, hogy egy ház tulajdonosa csak olyan valakinek adja el a házát, aki a házat az illetékes háztulajdonosok egyesületében szerepelteti továbbra is, ami viszont ugyanilyen állapothoz kötődik, tehát ebben az egyesületben lévőnek kell lennie a vevőnek is.

A Bitcoin közösség tagjai figyelmeztettek a rekurzív megállapodásokra, mivel attól tartanak, hogy lehetővé tehetik az AML- és KYC-szabályok invazív gyakorlatait, például egy rekurzív megállapodás, amely csak bizonyos, a KYC-információkkal társított bitcoin-címeket helyezi el az engedélyezési listán.

A CTV nem teszi lehetővé a rekurzív egyezményeket, mivel megköveteli, hogy minden jövőbeni tranzakciós adatot (amely a megállapodásban szerepel) ismerni kell a bitcoin cím létrehozásakor. Egy másik ilyen eljárás a CheckTXHashVerify viszont engedélyezheti a rekurzív megállapodást.

A megállapodások sokféleképpen használhatók lennének a Bitcoinban. Nézzünk meg ezek közül hármat, azzal, hogy jelenleg nincsenek módszerek a megállapodások/értéktárolók, stb láncon belüli érvényesítésére és sokan ellenzik is ezek használatát.

(Pl. az ún. OP_CAT (lásd még: II. rész) esetében az összefűzött értékek bizonyos költési feltételeket érvényesítenek, amelyek lehetővé teszik az értéktárakat és a megállapodásokat. Hogy mi is az az OP-CAT ezt egy következő blogposztban fogjuk megírni.)

Trezorok vagy értéktárak (OP_VAULT)

Az egyik módja annak, hogy a saját felügyeletet biztonságosabbá és praktikusabbá tegyük, a trezorok. A trezor egy hidegtároló bitcoin cím, amely csak egy előre meghatározott bitcoin címre tud küldeni. Ehhez az előre meghatározott bitcoin címhez időzár tartozik, ami azt jelenti, hogy csak bizonyos idő elteltével költhet. Az időzár mellett az előre meghatározott bitcoin címnek van egy ún. megállapodása (konszenzus kódja) is, amely lehetővé teszi a cím visszaküldését a hideg címére anélkül, hogy megvárná az időzárat.

A trezor vagy értéktár tehát egyfajta megállapodás, amely olyan költési feltételeket hoz létre, amelyekhez két különböző tranzakciónak két különálló blokkban kell megjelennie ahhoz, hogy a felhasználó elkölthesse a kapcsolódó bitcoint.

Ennek a kialakításnak a használatával lehetőség nyílik olyan pénztárca-megoldásra, amely egy előre meghatározott időzáron belül képes „törölni” a rosszindulatú tranzakciókat. Ha az időzárás az ideiglenes címen például 7 nap, a felhasználónak egy hete van arra, hogy ténylegesen „törölje” azt a kimenő tranzakciót, amelyet nem szándékozott elküldeni.

Torlódások szabályozása (OP_CHECKTEMPLATEVERIFY)

Egy másik érdekes szolgáltatás, amelyet a megállapodások engedélyezhetnek, a torlódások szabályozása. A torlódások szabályozásával a Bitcoin-felhasználók magasabb díjjal küldhetnek köztes tranzakciót, amely zárol egy jövőbeli tranzakciót. Ez például azt jelentheti, hogy magas díjak idején, amikor egy bitcoin tőzsdének általában nagy tranzakciót kell küldenie sok drága kimenettel, ehelyett csak egy kimenettel küldhet tranzakciót, amely arra kötelezi magát, hogy számos kimenetnek vagy fogadónak küld majd pénzeszközt ha a díjak alacsonyabbak lesznek.

Az ún. Csatornagyárak.

A Lightning hálózat méretezésére szolgáló „szövetségi” megoldás. A csatornagyárak villámcsatornák, amelyeket több mint 2 fél oszt meg. Lehetővé teszik a csatornagyár résztvevői számára, hogy csatornákat nyissanak meg egymás között anélkül, hogy további láncon belüli tranzakciókat kellene küldeniük.

Egy 3 résztvevős csatornagyárban minden résztvevő egy láncon belüli tranzakciót küldhet és 2 villámcsatornát fogadhat. Egy 4 résztvevős csatornagyárban ez résztvevőnként 3 villámcsatornára nő, és így tovább. A csatornagyárak csökkentik a láncon belüli lábnyomot azáltal, hogy több Lightning csatornát tesznek lehetővé láncon belüli tranzakciónként.

Vége az I. résznek.

Felhasznált irodalom: bitbox.swiss/blog