Den här artikeln handlar om ett teknologisk koncept baserat på den föreslagna uppgraderingen av Taproot-protokollet. Om du ännu inte känner till grunderna för hur Taproot fungerar rekommenderas det att du läser först den här förklararen.
Pålrot, en potentiell uppgradering till Bitcoin-protokollet som först föreslogs av Bitcoin Core-bidragsgivaren Gregory Maxwell, är i sina sena utvecklingsstadier. Tekniken består av en smart kombination av krypto-tricks som låter användare dölja komplexa smarta kontrakt i vanliga transaktioner - komplexiteten uppenbaras bara någonsin om parter i ett kontrakt inte är samarbetsvilliga.
Utnyttja denna idé har Bitcoin Core-bidragsgivare inklusive (men inte begränsat till) Jeremy Rubin, Antoine Riard, Gleb Naumenko och Gregory Maxwell själv spekulerat om ett allmänt begrepp som kallas betalning pooler, gå med i pooler eller myntpooler. Dessa pooler - vi kommer hålla oss till att kalla dem betalningspooler för nu - skulle låta grupper av användare dela ägandet av samma mynt (tekniskt: UTXO: er) som spelats in på Bitcoin blockchain, samtidigt som vi låter någon av dessa användare göra (eller ta emot) betalningar med dem. När gruppen och dess enskilda medlemmar "gömmer" sig i en Taproot-struktur, njuter de alla av mer integritet, smart kontraktsflexibilitet och andra fördelar ... och de kan även njuta av dessa fördelar utanför kedjan, vilket gör betalningspooler till en ny Layer Two-lösning.
Även om designdetaljer varierar lite från ett förslag till Payment Pool till det nästa, är det allmänna konceptet detsamma. Här är grundidén ...
Dela ett mynt
Först, för att skapa en betalningspool, kombinerar användare sina (bråkdelar av) mynt genom att samla dem i en Taproot-adress som delas mellan dem. Så, låt oss säga att Alice äger tre mynt, Bob äger två mynt och Carol äger ett mynt, för totalt sex. Tillsammans skapar de en transaktion som skickar dessa mynt till den delade adressen, vilket gör det till en betalningspool med sex mynt.
På blockchain ser betalningspooladressen ut som en vanlig Bitcoin-adress som nu har sex mynt. Men under ytan använde Alice, Bob och Carol på ett smart sätt Taproot för att säkerställa att var och en av dem förblir kontroll över sin egen andel av mynt i betalningspoolen. Alice kan när som helst kräva tre mynt från adressen, Bob kan när som helst kräva två och Carol ett.
Det beror på att det bara finns två huvudalternativ att spendera mynt från adressen.
Det första alternativet är att spendera direkt från adressen, i tekniska termer Taproot-nyckelvägen. Detta kräver samarbete (det vill säga: kryptografiska signaturer) från alla tre deltagarna. Om Alice, Bob och Carol alla är överens, kan de sex mynten spenderas hur de än vill, och det ser ut som alla andra vanliga transaktioner på Bitcoin-nätverket. Trioen kan till exempel bestämma sig för att skicka respektive saldo till enskilda adresser: tre för Alice, två för Bob och en för Carol. Men om de så skulle välja, kan de också samarbeta för att donera alla sex mynt till Julian, eller spendera det på något annat sätt som de kan komma överens om. Det viktiga är att alla tre måste delta, så att ingen balans spenderas utan hans eller hennes eget samarbete.
Det andra huvudalternativet består faktiskt av flera underalternativ. Innan de skickade sina mynt till betalningspoolen gömde Alice, Bob och Carol något i det kryptografiska trädet bakom Taproot-adressen: de inkluderade alternativa sätt att skicka medel från betalningspoolen. (För närvarande kan detta realiseras genom att alla tre deltagare förunderskriver transaktioner från dessa banor, vilket kräver viss komplexitet för att ställa in alla alternativ och inte skala så bra. Föreslagna protokolluppgraderingar kan möjligen göra det enklare i framtiden .)
Om en av deltagarna väljer att spendera mynten i betalningspoolen via en alternativ Taproot-väg, skickar de vanligtvis ett belopp som motsvarar den deltagares saldo till en adress som de väljer, som en individuell adress som de kontrollerar. (I Alice's fall tre mynt till hennes egen adress, i Bobs fall två till hans adress och i Carol's fall ett.)
Med hjälp av denna alternativa väg spenderas de återstående mynten också automatiskt. Detta kan göras på flera sätt beroende på utformningen av betalningspoolen och erbjuder olika avvägningar med avseende på komplexitet och skalbarhet.
Den enklaste lösningen är att skicka alla andra deltagare sin andel av mynt också till en adress som de väljer. Med andra ord: om en användare lämnar poolen, lämnar alla poolen.
En andra lösning, föredragen av Riard och Naumenko, är att skicka alla återstående mynt till en ny betalningspool, som ser exakt ut som den första betalningspoolen, bara borttagen från allt som involverade den nu avslutade användaren. Denna design erbjuder den bästa användarupplevelsen, men är den svåraste att skala, viktigast av allt eftersom det är nödvändigt att förbereda sig för alla möjliga utgångsscenarier, inklusive alla möjliga utgångsscenarier för alla potentiella nya pooler. Skala kunde emellertid uppnås med en ännu uppsatt potentiell Bitcoin-protokolluppgradering för att säkerställa att reglerna från den tidigare betalningspoolen överförs till alla nya betalningspooler.
Rubin anser dock att den andra lösningen är opraktisk och föredrar att gå efter något mellan den första och den andra lösningen: vissa deltagare får omedelbart sina mynt till en adress som de väljer, andra deltagare har sina mynt skickat till en ny betalningspool. Denna design erbjuder en mindre idealisk användarupplevelse, men skulle skala bättre och den potentiella OP_CHECKTEMPLATEVERIFY-protokolluppgraderingen skulle hjälpa till att förenkla designen och öka skalan ännu mer. (Utgångar skulle ske genom trädbetalningar; dessa typer av betalningar utforskas vidare i den här artikeln.)
(Det finns fler avvägningar mellan den andra och den tredje lösningen, men detaljerna om alla fördelar och nackdelar ligger utanför denna artikel; bitcoin-dev adresslista diskussion för detaljer.)
För att se vad det betyder när återstående mynt skickas till en ny betalningspool, låt oss säga att Alice, Bob och Carol väljer det andra alternativet, där alla återstående mynt skickas till en ny betalningspool. Om Alice i den här designen lämnar den första betalningspoolen skickas tre mynt till en adress som hon väljer, medan de andra tre mynten skickas till en ny betalningspool mellan Bob och Carol. Alice vid den tidpunkten har ensam kontroll över sina egna mynt igen, medan inte så mycket har förändrats för Bob och Carol. De två kan fortfarande samarbeta för att spendera de tre kvarvarande mynt som de än vill, eller någon av dem kan lämna ensidigt, som Alice hade gjort tidigare.
Om Bob sedan ensidigt lämnar den andra betalningspoolen skickar han två mynt till en adress som du väljer och ett mynt till en ännu nyare betalningspool (den tredje) med bara Carol kvar. (I detta förenklade exempel skulle naturligtvis en design där denna sista betalningspool ersätts med en adress som Carol valde skulle i själva verket vara mer meningsfull, men det är en implementeringsdetalj.)
Den viktiga takeawayen är att deltagare i en betalningspool kan samarbeta för att göra alla typer av betalningar från poolen de vill, medan någon av dem när som helst kan lämna sina egna mynt och lämna andra deltagare kontroll över deras.
Sätta betalningen i betalningspool
Så vi har fastställt att alla deltagare individuellt kan ta ut sitt saldo från en betalningspool, eller - om de alla är överens - spendera från poolen. Det är det andra alternativet som faktiskt möjliggör något smart: betalningspoolen kan vara dynamisk. Så länge alla deltagare är överens, kan de inte bara betala tillbaka sina pengar eller betala andra (som Julian), men de kan göra något ännu mer intressant. De kan flytta sina medel till nyare versioner av betalningspoolen med olika design.
Detta till exempel låter någon av dem spendera från poolen.
Låt oss säga att Alice köper en ny bil och vill betala för den med en bitcoin. Alice, Bob och Carol kunde sedan skapa en transaktion från betalningspoolen som skickar ett mynt till bilhandlaren och skickar de återstående fem mynten till en ny betalningspool som ser samma ut som den första, utom denna gång kan Alice bara lämna den ensidigt med två mynt, ett mindre än tidigare.
Transaktionen såg under tiden ut som alla andra vanliga Bitcoin-transaktioner. Bilhandlaren (eller blockchain-spionerna) kan dra slutsatsen att Alice ägde alla sex mynten och helt enkelt använde en för att köpa bilen och höll de andra fem som förändring. De hade ingen aning om att några av mynten tillhör Bob och Carol, eller att de alls var involverade i transaktionen.
Nästa gång, när Bob betalar och Alice och Carol samarbetar, görs det från samma betalningspool, och återigen ser ut som en vanlig Bitcoin-transaktion till omvärlden. I den resulterande iterationen av betalningspoolen kan Bob avsluta med ett mynt istället för två. Samtidigt kan samma blockchain-spioner trodde att Alice betalade igen och förvirrade dem ytterligare. (Och även om blockchain-spionerna på något sätt skulle räkna ut att adressen verkligen är en betalningspool mellan Alice, Bob och Carol, kunde de fortfarande inte veta vilken av de tre som gjorde den senaste betalningen.)
Varje gång Alice, Bob eller Carol spenderar mynt kan transaktionen komma från någon av dem, och ingen utanför betalningspoolen kan skilja skillnaden.
Betalningspooler tillåter inte bara utgifter. Om Alice vill fylla på sitt "saldo" i betalningspoolen, kan hon också göra det. Alice, Bob och Carol skulle i detta fall samarbeta för att flytta de nuvarande fem mynten till en ny Taproot-adress, till vilken Alice i samma transaktion skulle skicka ytterligare ett mynt från en av hennes egna (individuella) adresser. Den nya Taproot-adressen skulle återigen innehålla sex mynt, varav tre tillhör Alice, vilket återspeglas i hennes ensidiga utgångsalternativ.
På samma sätt kunde helt nya användare också gå med i betalningspoolen. Om Alice, Bob och Carol går med på att låta Dave delta, samarbetar de tre med Dave för att skapa en transaktion som skickar betalningspoolfonderna tillsammans med Daves nya mynt till en ny betalningspool, utformad för att också låta Dave delta - och avsluta om han skulle välja det.
Dessutom finns det möjlighet för deltagare i betalningspoolen att betala varandra. Om Alice till exempel skulle betala Bob ett mynt, kan de tre samarbeta för att skicka medlen till en ny betalningspool där Alice har ett mynt som dras från sitt saldo och Bob har lagt till ett mynt. På blockchain skulle det återigen se ut som en vanlig betalning, och blockchain-spioner har ingen aning om vem som betalade vem eller hur mycket. (Det är värt att påpeka att Dave på liknande sätt kunde komma in i poolen genom att få en intern betalning från en av de befintliga deltagarna.)
Med lite extra komplexitet (och helst med minst en extra Bitcoin-protokolluppgradering som Ingen ingång), kan överföringar även genomföras utanför kedjan. När Alice betalar Bob skulle alla deltagare i det här fallet skapa en transaktion som spenderar medel till en ny betalningspool precis samma, men denna transaktion skulle bara delas mellan dem - inte sänds till nätverket (såvida inte någon någonsin försöker fuska). På detta sätt kunde Alice, Bob och Carol fortsätta att uppdatera sin balans "internt" och till och med låta Dave i poolen vid någon tidpunkt. När de alla samtycker till att stänga poolen, kan de skapa en slutlig transaktion som spenderas från den ursprungliga betalningspoolen och tilldelar var sin senaste saldo.
Liknar en äldre idé känd som Kanalfabriker, dessa typer av betalningspooler kan så småningom till och med användas för att själva vara värd för Lightning-kanaler, valv eller andra Layer Two-protokoll. Detta kan ge möjlighet att "svepa" alla typer av ytterligare protokollskikt i sådana pooler och därmed dölja all deras komplexitet i identiska och regelbundna transaktioner.