RGB Magic: Ügyféloldali szerződések Bitcoinon

Ez Federico Tenga, a Bitcoin projektek hosszú távú közreműködője, start-up alapítóként, tanácsadóként és oktatóként tapasztalattal rendelkező szerkesztőségi szerkesztője.

Az „intelligens szerződések” kifejezés megelőzi a blokklánc és magának a Bitcoinnak a feltalálását. Első említése a Nick Szabó 1994-es cikke, aki az intelligens szerződéseket „számítógépes tranzakciós protokollként határozza meg, amely végrehajtja a szerződés feltételeit”. Míg ezen definíció szerint a Bitcoin a szkriptnyelvének köszönhetően már az első blokktól kezdve támogatta az intelligens szerződéseket, a kifejezést csak később tették népszerűvé az Ethereum promóterei, akik az eredeti definíciót úgy csavarták ki, hogy „a globális konszenzusban minden csomópont redundánsan hajtja végre a kódot. hálózat"

Míg a kódvégrehajtás globális konszenzusos hálózatra delegálása előnyökkel jár (pl. könnyű telepíteni a nem kötelezett szerződéseket, mint például a népszerűen automatizált piacjegyzők), ennek a kialakításnak van egy nagy hibája: a méretezhetőség (és az adatvédelem) hiánya. Ha a hálózat minden csomópontjának redundánsan ugyanazt a kódot kell futtatnia, akkor a ténylegesen végrehajtható kód mennyisége a csomópont üzemeltetési költségeinek túlzott növelése (és ezáltal a decentralizáció megőrzése) nélkül szűkös marad, ami azt jelenti, hogy csak kis számú szerződés köthető. végrehajtott.

De mi lenne, ha kialakíthatnánk egy olyan rendszert, amelyben a szerződés feltételeit csak az érintett felek hajtják végre és érvényesítik, nem pedig a hálózat összes tagja? Képzeljünk el egy olyan vállalat példáját, amely részvényeket akar kibocsátani. Ahelyett, hogy a kibocsátási szerződést nyilvánosan közzétennék egy globális főkönyvben, és ezt a főkönyvet használnák az összes jövőbeni tulajdonjog-átruházás nyomon követésére, egyszerűen csak privát módon bocsátaná ki a részvényeket, és a vevőkre ruházná át a további átruházás jogát. Ezután a tulajdonjog átruházásának joga minden új tulajdonosra átruházható, mintha az eredeti kibocsátási szerződés módosításáról lenne szó. Így minden tulajdonos önállóan ellenőrizheti az általa kapott részvények valódiságát, ha elolvassa az eredeti szerződést, és ellenőrzi, hogy a részvényeket áthelyező módosítások előzményei megfelelnek-e az eredeti szerződésben rögzített szabályoknak.

Ez valójában nem újdonság, valójában ugyanaz a mechanizmus, amelyet a tulajdon átruházására használtak, mielőtt a nyilvános nyilvántartások népszerűvé váltak. Az Egyesült KirályságbanPéldául a '90-es évekig nem volt kötelező egy ingatlant a tulajdonjog átruházásakor bejegyeztetni. Ez azt jelenti, hogy Angliában és Walesben még ma is több mint 15%-a nincs bejegyezve. Ha nem bejegyzett ingatlant vásárol, ahelyett, hogy a nyilvántartásban ellenőrizné, hogy az eladó-e a valódi tulajdonos, legalább 15 évre visszamenőleg megszakadatlan tulajdoni láncot kell igazolnia (ez az időszak elég hosszúnak tekinthető ahhoz, hogy feltételezzük, hogy az eladó elegendő tulajdonjog az ingatlanra). Ennek során meg kell győződnie arról, hogy a tulajdonjog átruházása megfelelően történt, és a korábbi ügyletekhez felhasznált jelzáloghiteleket maradéktalanul kifizették. Ennek a modellnek az az előnye, hogy jobb a magánélet a tulajdonjoggal szemben, és nem kell a nyilvános ingatlan-nyilvántartás kezelőjére hagyatkoznia. Másrészt a vevő számára sokkal bonyolultabbá teszi az eladó tulajdonjogának ellenőrzését.

Hogyan javítható a nem bejegyzett ingatlanok átadása? Először is úgy, hogy digitalizált folyamattá tesszük. Ha van olyan kód, amely számítógéppel lefuttatható annak ellenőrzésére, hogy a tulajdonjog átruházásának minden története megfelel-e az eredeti szerződési szabályoknak, akkor az adásvétel sokkal gyorsabbá és olcsóbbá válik.

Másodszor, annak elkerülése érdekében, hogy az eladó kétszer elköltse eszközét, be kell vezetni a közzététel igazolásának rendszerét. Például bevezethetnénk egy olyan szabályt, amely szerint minden tulajdonjog átruházást egy ismert újság előre meghatározott helyén kell végrehajtani (pl. a New York-i lap első oldalának jobb felső sarkába tegyük a tulajdonjog átruházásának hash-jét Times). Mivel az átutalás hash-jét nem helyezheti el kétszer ugyanarra a helyre, ez megakadályozza a dupla költekezést. Egy híres újság ilyen célra történő felhasználásának azonban van néhány hátránya:

1. Az ellenőrzési folyamathoz sok újságot kell vásárolnia. Nem túl praktikus.
2. Minden szerződésnek külön hely kell az újságban. Nem nagyon skálázható.
3. Az újságszerkesztő könnyen cenzúrázhatja, vagy ami még rosszabb, szimulálhatja a dupla költekezést, ha véletlenszerű hash-t tesz a nyílásba, amivel azt gondolhatja, hogy az eszköz potenciális vásárlója azt már eladta, és elriasztja a megvásárlásától. Nem túl bizalmatlan.

Ezen okok miatt jobb helyet kell találni a tulajdonjog átruházásáról szóló igazolások közzétételére. És mi lenne jobb megoldás, mint a Bitcoin blokklánc, egy már kialakult, megbízható nyilvános főkönyv, amely erős ösztönzőkkel bír a cenzúraálló és decentralizált megőrzésre?

Ha Bitcoint használunk, akkor ne adjunk meg egy fix helyet a blokkban, ahol a tulajdonjog átruházási kötelezettségének meg kell történnie (pl. az első tranzakciónál), mert akárcsak a New York Times szerkesztőjénél, a bányász ezzel is ronthat. Jobb megközelítés, ha a kötelezettségvállalást egy előre definiált Bitcoin-tranzakcióba helyezzük, pontosabban egy olyan tranzakcióba, amely egy el nem költött tranzakció kimenetből (UTXO) származik, amelyhez a kibocsátandó eszköz tulajdonjoga kapcsolódik. Az eszköz és a bitcoin UTXO közötti kapcsolat létrejöhet akár az eszközt kibocsátó szerződésben, akár a tulajdonjog egy későbbi átruházása során, minden alkalommal, amikor a cél UTXO az átadott eszköz vezérlőjévé válik. Ily módon egyértelműen meghatároztuk, hol legyen a tulajdonjog átruházási kötelezettsége (azaz egy adott UTXO-ból származó Bitcoin tranzakcióban). Bárki, aki Bitcoin-csomópontot használ, függetlenül tudja ellenőrizni a kötelezettségvállalásokat, és sem a bányászok, sem bármely más entitás nem tudja semmilyen módon cenzúrázni vagy beavatkozni az eszközátruházásba.

Mivel a Bitcoin blokkláncon csak a tulajdonjog átruházására vonatkozó kötelezettségvállalást tesszük közzé, magát az átruházás tartalmát nem, az eladónak szüksége van egy dedikált kommunikációs csatornára, hogy a vevő minden igazolást megkapjon a tulajdonjog-átruházás érvényességéről. Ezt többféleképpen meg lehet tenni, akár úgy is, hogy kinyomtatják a próbanyomatokat, és postagalambbal szállítják őket, ami bár kissé kivitelezhetetlen, mégis ellátná a feladatot. De a legjobb megoldás a cenzúra és a magánélet megsértésének elkerülésére egy közvetlen peer-to-peer titkosított kommunikáció kialakítása, amelynek a galambokhoz képest az is előnye, hogy könnyen integrálható a partnertől kapott igazolásokat ellenőrző szoftverrel.

Ez az imént ismertetett modell az ügyféloldali érvényesített szerződéseknél és a tulajdonjog-átruházásoknál pontosan az, amit az RGB protokollal megvalósítottak. Az RGB segítségével lehetőség nyílik olyan szerződés létrehozására, amely meghatározza a jogokat, hozzárendeli azokat egy vagy több létező bitcoin UTXO-hoz, és meghatározza a tulajdonjog átruházásának módját. A szerződés egy sablonból, úgynevezett „sémából” kiindulva hozható létre, amelyben a szerződés létrehozója csak a paramétereket és a tulajdonosi jogokat módosítja, ahogy az a hagyományos jogi szerződéseknél történik. Jelenleg kétféle séma létezik az RGB-ben: az egyik helyettesíthető tokenek kiadására szolgál (RGB20) és egy második a gyűjtők kiadására (RGB21), de a jövőben bárki több sémát fejleszthet ki engedély nélkül, anélkül, hogy protokollszinten kellene változtatni.

Gyakorlatiasabb példával élve, a helyettesíthető eszközök (pl. vállalati részvények, stabil érmék stb.) kibocsátója használhatja az RGB20 séma sablont, és létrehozhat egy szerződést, amelyben meghatározza, hány tokent ad ki, az eszköz nevét és néhány további metaadatot. ezzel. Ezután meghatározhatja, hogy melyik bitcoin UTXO-nak van joga átruházni a létrehozott tokenek tulajdonjogát, és más UTXO-kra más jogokat rendelni, például másodlagos kibocsátásra vagy az eszköz újranominálására. Minden ügyfél, aki a jelen szerződéssel létrehozott tokeneket kapja, ellenőrizheti a Genesis szerződés tartalmát, és ellenőrizheti, hogy a kapott token történetében szereplő tulajdonjog átruházása megfelelt-e az abban foglalt szabályoknak.

Mit tehetünk tehát az RGB-vel a gyakorlatban? Mindenekelőtt a tokenizált eszközök kibocsátását és átvitelét teszi lehetővé bármely létező alternatívához képest jobb méretezhetőség és adatvédelem mellett. Adatvédelmi oldalon az RGB előnyére válik, hogy az átvitellel kapcsolatos összes adatot kliensoldalon tárolják, így a blokklánc-figyelő semmilyen információt nem tud kinyerni a felhasználó pénzügyi tevékenységeiről (még az RGB kötelezettségvállalást tartalmazó bitcoin tranzakciót sem lehet megkülönböztetni a szokásostól), ráadásul a fogadó csak a vak UTXO-t (azaz az UTXO, amelyben az eszközöket fogadni kívánja, és egy véletlen szám közötti összefűzés hash-ét) osztja meg a küldővel, nem pedig magát az UTXO-t, tehát nem a fizető fél figyelemmel kísérheti a címzett jövőbeni tevékenységét. A felhasználók magánéletének további növelése érdekében az RGB a golyóálló kriptográfiai mechanizmust is alkalmazza, hogy elrejtse az eszközátruházások történetében szereplő összegeket, így még az eszközök jövőbeni tulajdonosai is homályos képet kapnak a korábbi tulajdonosok pénzügyi viselkedéséről.

A méretezhetőség szempontjából az RGB bizonyos előnyöket is kínál. Először is, az adatok nagy részét a láncon kívül tárolják, mivel a blokkláncot csak kötelezettségvállalási rétegként használják, ami csökkenti a fizetendő díjakat, és azt jelenti, hogy minden ügyfél csak az őt érdeklő átutalásokat érvényesíti, nem pedig az összes globális hálózat tevékenysége. Mivel az RGB átutaláshoz továbbra is Bitcoin-tranzakcióra van szükség, a díjmegtakarítás minimálisnak tűnhet, de amikor elkezdi bevezetni a tranzakciókötegelést, gyorsan hatalmassá válhat. Valójában lehetőség van egy UTXO-hoz kapcsolódó összes token (vagy általánosabban: „jogok”) átruházása tetszőleges számú címzettre, egyetlen kötelezettségvállalással egyetlen bitcoin-tranzakcióban. Tegyük fel, hogy Ön egy szolgáltató, aki egyszerre több felhasználónak fizet kifizetéseket. Az RGB segítségével egyetlen Bitcoin-tranzakcióval több ezer átutalást hajthat végre több ezer felhasználónak, akik különböző típusú eszközöket kérnek, így minden egyes kifizetés határköltsége teljesen elhanyagolható.

A kis értékű eszközök kibocsátóinak másik díjmegtakarítási mechanizmusa az, hogy RGB-ben egy eszköz kibocsátásához nem kell díjat fizetni. Ez azért történik, mert a kibocsátási szerződés létrehozását nem kell elkötelezni a blokkláncon. A szerződés egyszerűen meghatározza, hogy az újonnan kibocsátott eszközök melyik már meglévő UTXO-hoz lesznek hozzárendelve. Tehát ha Ön egy művész, aki érdeklődik a gyűjthető tokenek készítése iránt, akkor annyit bocsáthat ki ingyen, amennyit csak akar, majd csak akkor fizetheti ki a bitcoin tranzakciós díjat, amikor megjelenik egy vevő, és kéri a token hozzárendelését az UTXO-hoz.

Továbbá, mivel az RGB a bitcoin tranzakciókra épül, kompatibilis a Lightning Network-tel is. Bár a cikk írásakor még nincs implementálva, lehetőség lesz eszközspecifikus Lightning-csatornák létrehozására és a fizetések rajtuk keresztül történő irányítására, hasonlóan ahhoz, ahogyan a normál Lightning-tranzakcióknál működik.

Következtetés

Az RGB egy úttörő innováció, amely egy teljesen új paradigma segítségével új felhasználási esetek felé nyit, de milyen eszközök állnak rendelkezésre a használatához? Ha magával a technológia magjával szeretne kísérletezni, akkor közvetlenül ki kell próbálnia a RGB csomópont. Ha alkalmazásokat szeretne RGB-n felül építeni anélkül, hogy mélyen bele kellene merülnie a protokoll összetettségébe, használhatja a rgb-lib könyvtár, amely egyszerű felületet biztosít a fejlesztők számára. Ha csak eszközöket szeretne kibocsátani és átruházni, játszhat vele Iris Wallet Androidra, amelynek kódja szintén nyílt forráskódú GitHub. Ha csak többet szeretne megtudni az RGB-ről, nézze meg az erőforrások ezen listáját.

Ez Federico Tenga vendégbejegyzése. A kifejtett vélemények teljes mértékben a sajátjuk, és nem feltétlenül tükrözik a BTC Inc vagy a Bitcoin Magazine véleményét.