Ez a cikk a Taproot protokoll javasolt frissítésén alapuló technológiai koncepcióról szól. Ha még nem ismeri a Taproot működésének alapjait, javasoljuk, hogy először olvassa el ez a magyarázó.
érintse meg a gyökeret, a Bitcoin protokoll egy lehetséges frissítése, amelyet először a Bitcoin Core közreműködője, Gregory Maxwell javasolt, a fejlesztés késői szakaszában jár. A technológia kriptotrükkök okos kombinációjából áll, amely lehetővé teszi a felhasználók számára, hogy bonyolult intelligens szerződéseket rejtsenek el a szokásosnak tűnő tranzakciókba – a bonyolultság csak akkor derül ki, ha a szerződő felek nem együttműködnek.
Ezt az ötletet kihasználva a Bitcoin Core közreműködői, köztük (de nem kizárólagosan) Jeremy Rubin, Antoine Riard, Gleb Naumenko és maga Gregory Maxwell egy általános koncepcióról spekulálnak fizetési medencék, joinpools vagy érmegyűjtők. Ezek a készletek – egyelőre maradunk a fizetési pooloknak nevezve – lehetővé tennék, hogy a felhasználók csoportjai ugyanazon érmék (technikailag: UTXO-k) tulajdonjogát megosszák, mint a Bitcoin blokkláncán, miközben ezek a felhasználók fizetéseket hajthatnak végre (vagy fogadhatnak). velük. Ahogy a csoport és egyes tagjai „bújnak” a Taproot struktúrába, mindannyian több magánéletet, intelligens szerződéses rugalmasságot és egyéb előnyöket élveznek… és potenciálisan még a láncon kívül is élvezhetik ezeket az előnyöket, így a fizetési csoportok egy új Layer Two megoldássá válnak.
Bár a tervezési sajátosságok fizetési pool-javaslatonként kissé eltérnek, az általános koncepció ugyanaz. Íme az alapötlet…
Érme megosztása
Először is, hogy létrehozzanak egy fizetési készletet, a felhasználók egyesítik érméiket (töredékeiket) úgy, hogy a maguk között megosztott Taproot címben összesítik őket. Tehát tegyük fel, hogy Alice három érmét birtokol, Bobnak két érmét, Carolnak pedig egy érmét, vagyis összesen hatot. Együtt létrehoznak egy tranzakciót, amely elküldi ezeket az érméket a megosztott címre, így hat érméből álló fizetési készletet alkot.
A blokkláncon a fizetési készlet címe úgy néz ki, mint egy szokásos Bitcoin cím, most hat érmével. De a felszín alatt Alice, Bob és Carol ügyesen használta a Taproot-ot annak biztosítására, hogy mindegyikük továbbra is kézben tartsa a saját érmék részesedését a fizetési készletben. Alice bármikor lekérhet három érmét a címről, Bob kettőt, Carol pedig egyet.
Ennek az az oka, hogy csak két fő lehetőség van a címből származó érmék elköltésére.
Az első lehetőség az, hogy közvetlenül a címről költsünk, szakszóval a Taproot kulcsútvonalról. Ez együttműködést (vagyis: kriptográfiai aláírást) igényel mindhárom résztvevőtől. Ha Alice, Bob és Carol egyetért, a hat érmét tetszés szerint elkölthetik, és ez úgy fog kinézni, mint bármely más szokásos tranzakció a Bitcoin hálózaton. A trió például dönthet úgy, hogy visszaküldi egyenlegét egyéni címekre: hármat Alice-nek, kettőt Bobnak és egyet Carolnak. De ha úgy döntenek, együttműködhetnek abban is, hogy mind a hat érmét Juliannek adományozzák, vagy bármilyen más módon elkölthetik, amiben megegyezhetnek. Az a fontos, hogy mindhármuknak részt kell venniük, így senki nem költi el az egyenlegét saját közreműködése nélkül.
A második fő lehetőség tulajdonképpen több allehetőségből áll. Mielőtt elküldték volna érméiket a fizetési készletbe, Alice, Bob és Carol elrejtett valamit a Taproot cím mögé található kriptográfiai fában: alternatív módokat is beépítettek arra, hogy pénzt küldjenek a fizetési készletből. (Jelenleg ez úgy valósítható meg, hogy mindhárom résztvevő előre aláírja a tranzakciókat ezekről az útvonalakról, ami némi bonyolultságot igényelne az összes opció beállításához, és nem skálázódik túl jól; a javasolt protokollfrissítések ezt a jövőben megkönnyíthetik. .)
Ha az egyik résztvevő úgy dönt, hogy a fizetési készletben lévő érméket egy alternatív Taproot útvonalon költi el, akkor általában az adott résztvevő egyenlegének megfelelő összeget küldene egy általa választott címre, például egy általa irányított egyéni címre. (Alice esetében három érme a saját címére, Bob esetében kettő a címére, Carol esetében pedig egy.)
Ezt az alternatív utat használva a maradék érméket is automatikusan elköltjük. Ez a fizetési készlet kialakításától függően többféle módon is megtehető, különböző kompromisszumokat kínálva a bonyolultság és a méretezhetőség tekintetében.
A legegyszerűbb megoldás, ha minden más résztvevőnek is elküldi a rá eső érmét, az általa választott címre. Más szóval: ha egy felhasználó kilép a készletből, mindenki kilép a készletből.
A Riard és Naumenko által előnyben részesített másik megoldás az, hogy az összes megmaradt érmét a új fizetési készlet, amely pontosan úgy néz ki, mint az első fizetési készlet, csak megfosztva mindentől, ami a most kilépett felhasználót érintette. Ez a kialakítás kínálja a legjobb felhasználói élményt, de a legnehezebben méretezhető, ami a legfontosabb, mert fel kell készülni az összes lehetséges kilépési forgatókönyvre, beleértve az összes lehetséges kilépési forgatókönyvet az összes lehetséges új készlet esetében. A méretarány azonban elérhető egy még meg nem nevezett potenciális Bitcoin-protokoll-frissítéssel, amely biztosítja, hogy a korábbi fizetési készlet szabályai átkerüljenek minden új fizetési készletbe.
Rubin azonban úgy véli, hogy ez a második megoldás nem praktikus, és inkább az első és a második megoldás közé esik: egyes résztvevők azonnal megkapják az érméket az általuk választott címre, mások pedig egy új fizetési készletbe küldik az érméket. Ez a kialakítás kevésbé ideális felhasználói élményt kínál, de jobban skálázható, és a lehetséges OP_CHECKTEMPLATEVERIFY protokollfrissítés segít a tervezés egyszerűsítésében és a méretarány növelésében. (A kilépés a Tree Paymentsen keresztül történne; az ilyen típusú fizetéseket részletesebben tárgyaljuk ezt a cikket.)
(Több kompromisszum van a második és a harmadik megoldás között, de az előnyök és hátrányok részletei kívül esnek e cikk keretein; olvassa el a bitcoin-dev levelezőlista vita a részletekért.)
Ha látni szeretné, mit jelent, ha a fennmaradó érméket egy új fizetési készletbe küldik, tegyük fel, hogy Alice, Bob és Carol a második lehetőséget választják, ahol minden a fennmaradó érméket egy új fizetési készletbe küldik. Ha ebben a tervben Alice kilép az első fizetési készletből, három érmét küldenek az általa választott címre, míg a másik három érmét egy új fizetési készletbe küldik Bob és Carol között. Alice ezen a ponton ismét egyedül irányítja saját érméit, míg Bob és Carol esetében nem sok minden változott. Ők ketten továbbra is együttműködhetnek, és tetszés szerint elkölthetik a maradék három érmét, vagy bármelyikük egyoldalúan kiléphet, ahogy Alice korábban tette.
Ha Bob egyoldalúan kilép a második fizetési készletből, akkor két érmét küld egy általa választott címre, és egy érmét egy még újabb fizetési csoportba (a harmadikba), ahol csak Carol maradt. (Természetesen ebben az egyszerűsített példában az a terv, amelyben az utolsó fizetési csoportot Carol által választott címre cseréli, a valóságban értelmesebb lenne, de ez egy megvalósítási részlet.)
A legfontosabb dolog az, hogy a fizetési pool résztvevői együttműködhetnek, és bármilyen típusú fizetést végrehajthatnak a készletből, miközben bármelyikük bármikor kiléphet saját érméivel, így a többi résztvevő az övék felett marad.
A fizetés elhelyezése a fizetési készletben
Így megállapítottuk, hogy minden résztvevő egyénileg kiveheti egyenlegét a fizetési készletből, vagy – ha mindannyian egyetértenek – költhet a poolból. Ez a második lehetőség valójában valami okos dolgot tesz lehetővé: a fizetési készlet dinamikus lehet. Mindaddig, amíg minden résztvevő egyetért, nem csak saját magának fizetheti vissza a pénzét, vagy fizethet másoknak (például Juliannak), hanem valami még érdekesebbet is tehet. A pénzeszközeiket áthelyezhetik a fizetési készlet újabb verzióiba, eltérő kialakítással.
Ez például lehetővé teszi, hogy bármelyikük költsön a medencéből.
Tegyük fel, hogy Alice új autót vesz, és egy bitcoinnal akar fizetni érte. Alice, Bob és Carol ezután létrehozhat egy tranzakciót a fizetési készletből, amely egy érmét küld az autókereskedésnek, a maradék öt érmét pedig egy új fizetési pool, amely ugyanúgy néz ki, mint az első, de Alice ezúttal csak két érmével tud egyoldalúan kilépni belőle, eggyel kevesebbel, mint korábban.
A tranzakció eközben úgy nézett ki, mint bármely más szokásos Bitcoin-tranzakció. Az autókereskedés (vagy blokklánc-kémek) arra a következtetésre juthat, hogy Alice birtokolta mind a hat érmét, és az egyiket egyszerűen az autó megvásárlására használta, a másik ötöt pedig aprópénznek tartotta. Fogalmuk sem volt arról, hogy az érmék egy része Bob és Carol tulajdona, vagy hogy egyáltalán részt vettek a tranzakcióban.
Legközelebb, amikor Bob befizet, és Alice és Carol együttműködnek, az ugyanabból a fizetési csoportból történik, és ismét egy közönséges Bitcoin-tranzakciónak tűnik a külvilág számára. A fizetési készlet eredményül kapott iterációjában Bob kettő helyett egy érmével léphet ki. Eközben ugyanazok a blokklánc-kémek azt gondolhatták, hogy Alice ismét fizet, ami tovább zavarta őket. (És még ha a blokklánc-kémek valahogy rájönnének is, hogy a cím valóban egy fizetési bázis Alice, Bob és Carol között, még mindig nem tudnák megmondani, hogy a három közül melyik fizette a legutóbb.)
Valahányszor Alice, Bob vagy Carol érméket költ, a tranzakció bármelyiküktől származhat, és a fizetési készleten kívül senki sem tudja megkülönböztetni.
A fizetési alapok nem csak költekezést tesznek lehetővé. Ha Alice szeretné feltölteni az „egyenlegét” a fizetési poolban, ezt is megteheti. Alice, Bob és Carol ebben az esetben együttműködnek, hogy a jelenlegi öt érmét egy új Taproot címre helyezzék át, amelyre Alice ugyanabban a tranzakcióban küldene egy további érmét a saját (egyéni) címei közül. Az új Taproot cím ismét hat érmét tartalmazna, amelyek közül három Alice-é, amint az egyoldalú kilépési lehetőségében is tükröződik.
Ugyanígy teljesen új felhasználók is csatlakozhattak a fizetési poolhoz. Ha Alice, Bob és Carol beleegyeznek abba, hogy Dave részt vegyen, hárman együttműködnek Dave-vel, hogy létrehozzanak egy tranzakciót, amely a fizetési készletet Dave új érméivel együtt egy új fizetési készletbe küldi, amely lehetővé teszi, hogy Dave is részt vegyen – és kilépjen. ha úgy döntene.
Ezenkívül lehetőség van a fizetési csoporton belüli résztvevők számára, hogy fizessenek egymásnak. Ha Alice például egy érmét fizetne Bobnak, akkor a hárman együttműködhetnének, hogy az összeget egy új fizetési csoportba küldjék, ahol Alice egyenlegéből levon egy érmét, Bobnak pedig egy érmét ad hozzá. A blokkláncon ez megint úgy nézne ki, mint egy rendes fizetés, és a blokklánc-kémeknek fogalmuk sem lenne, hogy ki fizetett és mennyit. (Érdemes kiemelni, hogy Dave hasonló módon bekerülhetett volna a poolba, ha belső kifizetést kapott valamelyik meglévő résztvevőtől.)
Egy kis extra bonyolultsággal (és ideális esetben legalább egy extra Bitcoin protokoll frissítéssel, mint pl Nincs bemenet), az átvitelek akár a láncon kívül is végrehajthatók. Amikor Alice fizet Bobnak, ebben az esetben minden résztvevő létrehoz egy tranzakciós költési forrást egy új fizetési készletbe, de ezt a tranzakciót csak közöttük osztják meg – nem közvetítik a hálózatnak (hacsak valaki nem kísérel meg csalni). Ily módon Alice, Bob és Carol folyamatosan frissíthetik az egyensúlyukat „belsőleg”, és még Dave-et is beengedhetik valamikor a medencébe. Amikor mindannyian beleegyeznek a készlet bezárásába, létrehozhatnak egy végső tranzakciót, amely az eredeti fizetési csoportból költ, és mindegyikük megkapja a legutóbbi egyenlegét.
Hasonló egy régebbi ötlethez Csatornagyárak, az ilyen típusú fizetési készletek végül akár saját maguk is használhatók Lightning csatornák, trezorok vagy más Layer Two protokollok tárolására. Ez lehetőséget nyújthat bármilyen típusú további protokollréteg „becsomagolására” az ilyen készletekben, így elrejtve azok teljes bonyolultságát az azonos és szabályosnak tűnő tranzakciókban.