Den här artikeln handlar om ett teknologikoncept baserat på den föreslagna Taproot-protokolluppgraderingen. Om du ännu inte känner till grunderna för hur Taproot fungerar rekommenderas att du först läser den här förklararen.

Taproot, en potentiell uppgradering av Bitcoin-protokollet som först föreslogs av Bitcoin Core-bidragsgivaren Gregory Maxwell, är i sina sena utvecklingsstadier. Teknologin består av en smart kombination av krypto-tricks som låter användare dölja komplexa smarta kontrakt i vanliga transaktioner – komplexiteten avslöjas bara om parterna i ett kontrakt inte samarbetar.

Utnyttjande av denna idé har Bitcoin Core-bidragsgivare inklusive (men inte begränsat till) Jeremy Rubin, Antoine Riard, Gleb Naumenko och Gregory Maxwell själv spekulerat i ett allmänt koncept som kallas betalningspooler, joinpools eller myntpooler. Dessa pooler – vi håller fast vid att kalla dem betalningspoolar för tillfället – skulle låta grupper av användare dela äganderätten till samma mynt (tekniskt: UTXO: er) som registrerats i Bitcoin blockchain, samtidigt som någon av dessa användare gör (eller tar emot) betalningar med dem. Eftersom gruppen och dess enskilda medlemmar “gömmer sig” i en Taproot-struktur får de alla mer integritet, smart kontraktsflexibilitet och andra fördelar … och de kan till och med njuta av dessa fördelar utanför kedjan, vilket gör betalningspooler till en ny Layer Two-lösning.

Även om designspecifikationerna varierar lite från ett betalningspoolförslag till ett annat är det allmänna konceptet detsamma. Här är grundidén …

Dela ett mynt

För det första, för att skapa en betalningspool, kombinerar användare sina (bråkdelar) mynt genom att aggregera 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, 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 rymmer sex mynt. Men under ytan använde Alice, Bob och Carol smarta Taproot för att se till att var och en av dem förblir kontroll över sin egen andel mynt i betalningspoolen. Alice kan när som helst göra anspråk på tre mynt från adressen, Bob kan när som helst göra anspråk på 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 vill, och detta kommer att se ut som alla andra vanliga transaktioner i Bitcoin-nätverket. Trioen kan till exempel besluta att skicka tillbaka sina respektive saldon till enskilda adresser: tre för Alice, två för Bob och en för Carol. Men om de skulle välja så skulle de också kunna samarbeta för att donera alla sex mynt till Julian, eller spendera det på något annat sätt som de skulle komma överens om. Det viktiga är att alla tre behöver delta, så att ingen balans används utan hans eller hennes eget samarbete.

Det andra huvudalternativet består faktiskt av flera underalternativ. Innan Alice, Bob och Carol skickade sina mynt till betalningspoolen gömde de något i det kryptografiska trädet bakom Taproot-adressen: de inkluderade alternativa sätt att skicka pengar från betalningspoolen. (För närvarande kan detta realiseras genom att alla tre deltagarna förhandlar om transaktioner från dessa banor, vilket skulle kräva viss komplexitet för att ställa in alla alternativ och inte skalas särskilt bra; föreslagna protokolluppgraderingar kan möjligen göra det lättare i framtiden .)

Om en av deltagarna väljer att spendera mynten i betalningspoolen genom en alternativ Taproot-bana skickar de vanligtvis ett belopp som motsvarar deltagarens saldo till en adress som de väljer, som en individuell adress som de kontrollerar. (I Alis fall tre mynt till hennes egen adress, i Bobs fall två till hans adress och i Carols fall ett.)

Med den här alternativa vägen spenderas också de återstående mynten automatiskt. Detta kan göras på flera sätt beroende på betalningspoolens utformning, vilket erbjuder olika avvägningar vad gäller komplexitet och skalbarhet.

Den enklaste lösningen är att skicka alla andra deltagare sin del 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 ut precis som den första betalningspoolen, som bara tas bort från allt som involverar den nu existerade användaren. Denna design ger 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 kan dock uppnås med en ännu inte utnämnd potentiell Bitcoin-protokolluppgradering för att säkerställa att reglerna från den tidigare betalningspoolen överförs till en ny betalningspool.

Rubin anser dock att den andra lösningen är opraktisk och föredrar att gå mellan något mellan den första och andra lösningen: vissa deltagare får omedelbart sina mynt till en adress de väljer, andra deltagare får sina mynt skickade 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 via Tree Payments; 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 för alla fördelar och nackdelar ligger utanför denna artikel; läs bitcoin-dev e-postlista 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 tiden 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 mynten hur de än vill, eller någon av dem kan lämna ensidigt, som Alice hade gjort tidigare.

Om Bob sedan går ut ensidigt från den andra betalningspoolen skickar han två mynt till en adress som han väljer och ett mynt till en ännu nyare betalningspool (den tredje) med bara Carol kvar. (Naturligtvis, i detta förenklade exempel, skulle en design där den sista betalningspoolen ersätts med en adress som Carol valde i själva verket vara mer meningsfull, men det är en implementeringsdetalj.)

Det viktiga takeaway är att deltagare i en betalningspool kan samarbeta för att göra vilken typ av betalning som helst från poolen de vill, medan någon av dem kan när som helst lämna med sina egna mynt och lämna andra deltagare kontroll över sina.

Att 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 detta andra alternativ 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 mönster.

Detta låter till exempel 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 kan 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 likadan ut som den första, förutom den här gången kan Alice bara lämna ensidigt med två mynt, ett mindre än tidigare.

Transaktionen såg under tiden ut som alla andra vanliga Bitcoin-transaktioner. Bilhandlare (eller blockchain-spioner) kan dra slutsatsen att Alice ägde alla sex mynt och helt enkelt använde ett för att köpa bilen och behöll de andra fem som byte. De skulle inte ha någon aning om att några av mynten tillhör Bob och Carol, eller att de alls var inblandade i transaktionen.

Nästa gång, när Bob gör en betalning och Alice och Carol samarbetar, görs den från samma betalningspool, som återigen ser ut som en vanlig Bitcoin-transaktion för omvärlden. I den resulterande iterationen av betalningspoolen kan Bob lämna med ett mynt istället för två. Under tiden kan samma blockchain-spioner ha trott att Alice gjorde en betalning 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 berätta vilken av de tre som gjorde den senaste betalningen.)

Varje gång Alice, Bob eller Carol spenderar mynt kan transaktionen ha kommit från någon av dem, och ingen utanför betalningspoolen kan se 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 exitalternativ.

På samma sätt kan helt nya användare gå med i betalningspoolen också. 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 betalningspoolmedlen tillsammans med Daves nya mynt till en ny betalningspool, utformad för att också låta Dave delta – och lämna om han skulle välja det.

Dessutom finns det möjlighet för deltagare inom betalningspoolen att betala varandra. Om Alice till exempel skulle betala Bob ett mynt, kunde de tre samarbeta för att skicka pengarna till en ny betalningspool där Alice har ett mynt subtraherat från sin saldo och Bob har ett mynt tillagt. På blockchain skulle det åter se ut som en vanlig betalning, och blockchain-spioner hade ingen aning om vem som betalade vem eller hur mycket. (Det är värt att påpeka att Dave på samma sätt kunde ha gått 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 Noinput), kan överföringar till och med genomföras utanför kedjan. När Alice betalar Bob skulle alla deltagare i det här fallet skapa en transaktion som spenderar pengar till en ny betalningspool på samma sätt, men den här transaktionen delas bara 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 släppa Dave i poolen någon gång. När de alla går med på att stänga poolen kan de skapa en slutlig transaktion som spenderas från den ursprungliga betalningspoolen och tilldela var och en deras senaste saldo.

I likhet med en äldre idé som kallas Channel Factories, kan dessa typer av betalningspoolar så småningom även användas för att själva vara värd för blixtkanaler, valv eller andra Layer Two-protokoll. Detta kan erbjuda potentialen att “linda” alla typer av ytterligare protokolllager i sådana pooler, vilket döljer all deras komplexitet i identiska och regelbundet utseende transaktioner.