Denne artikel handler om et teknologisk koncept baseret på den foreslåede Taproot-protokolopgradering. Hvis du endnu ikke er bekendt med det grundlæggende i, hvordan Taproot fungerer, anbefales det, at du først læser denne forklaring.

Taproot, en mulig opgradering af Bitcoin-protokollen, der først blev foreslået af Bitcoin Core-bidragyder Gregory Maxwell, er i sine sene stadier af udvikling. Teknologien består af en smart kombination af krypto-tricks, der gør det muligt for brugere at skjule komplekse smarte kontrakter i regelmæssigt udseende transaktioner – kompleksiteten afsløres kun nogensinde, hvis parterne i en kontrakt ikke er samarbejdsvillige.

Udnyttelse af denne idé har Bitcoin Core-bidragydere, herunder (men ikke begrænset til) Jeremy Rubin, Antoine Riard, Gleb Naumenko og Gregory Maxwell selv spekuleret i et generelt koncept kaldet betalingspuljer, joinpools eller møntbassiner. Disse puljer – vi holder fast ved at kalde dem betalingspuljer for nu – ville lade grupper af brugere dele ejerskab af de samme mønter (teknisk: UTXO’er) som registreret i Bitcoin blockchain, mens de lader nogen af ​​disse brugere foretage (eller modtage) betalinger med dem. Da gruppen og dens individuelle medlemmer “gemmer sig” i en Taproot-struktur, nyder de alle mere privatliv, smart kontraktfleksibilitet og andre fordele … og de nyder potentielt endda disse fordele uden for kæden, hvilket gør betalingspuljer til en ny Layer Two-løsning.

Selvom designspecifikationer varierer lidt fra det ene betalingspuljeforslag til det næste, er det generelle koncept det samme. Her er den grundlæggende idé …

Deling af en mønt

For det første for at oprette en betalingspulje kombinerer brugerne deres (fraktioner af) mønter ved at samle dem i en Taproot-adresse, der deles mellem dem. Lad os sige, at Alice ejer tre mønter, Bob ejer to mønter, og Carol ejer en mønt, i alt seks. Sammen opretter de en transaktion, der sender disse mønter til den delte adresse, hvilket gør det til en betalingspulje med seks mønter.

På blockchain ser betalingspooladressen ud som en almindelig Bitcoin-adresse, der nu indeholder seks mønter. Men under overfladen brugte Alice, Bob og Carol dygtigt Taproot til at sikre, at hver af dem forbliver i kontrol med deres egen andel af mønter i betalingspuljen. Alice kan til enhver tid kræve tre mønter fra adressen, Bob kan til enhver tid kræve to og Carol en.

Dette skyldes, at der kun er to hovedmuligheder for at bruge mønter fra adressen.

Den første mulighed er at bruge direkte fra adressen, teknisk set, Taproot-nøglestien. Dette kræver samarbejde (dvs. kryptografiske signaturer) fra alle tre deltagere. Hvis Alice, Bob og Carol alle er enige, kan de seks mønter bruges, uanset hvordan de vil, og dette vil se ud som enhver anden regelmæssig transaktion på Bitcoin-netværket. Trioen kan f.eks. Beslutte at sende deres respektive saldi tilbage til individuelle adresser: tre til Alice, to til Bob og en til Carol. Men hvis de vælger det, kan de også samarbejde om at donere alle seks mønter til Julian eller bruge det på en anden måde, de måtte blive enige om. Det vigtige er, at de alle tre har brug for at deltage, så ingen bruger balance uden hans eller hendes eget samarbejde.

Den anden hovedmulighed består faktisk af flere underindstillinger. Før Alice, Bob og Carol sendte deres mønter til betalingspuljen, skjulte de noget i det kryptografiske træ bag Taproot-adressen: de inkluderede alternative måder at sende penge fra betalingspuljen. (I øjeblikket kunne dette realiseres ved at have alle tre deltagere til at underskrive transaktioner fra disse stier, hvilket ville kræve en vis kompleksitet for at opsætte alle muligheder og ikke skaleres særlig godt; foreslåede protokolopgraderinger kan muligvis gøre dette lettere i fremtiden .)

Hvis en af ​​deltagerne vælger at bruge mønterne i betalingspuljen gennem en alternativ Taproot-sti, vil de typisk sende et beløb svarende til den deltagers saldo til en adresse, de vælger, som en individuel adresse, som de kontrollerer. (I Alice’s tilfælde tre mønter til hendes egen adresse, i Bobs tilfælde to til hans adresse og i Carol’s tilfælde en.)

Ved hjælp af denne alternative sti bruges de resterende mønter også automatisk. Dette kan gøres på flere måder afhængigt af betalingspuljens design og tilbyder forskellige kompromiser med hensyn til kompleksitet og skalerbarhed.

Den enkleste løsning er at sende alle andre deltagere også deres andel af mønter til en adresse, de vælger. Med andre ord: hvis en bruger går ud af puljen, kommer alle ud af puljen.

En anden løsning, foretrukket af Riard og Naumenko, er at sende alle de resterende mønter til en ny betalingspulje, der ser ud nøjagtigt som den første betalingspulje, bare fjernet fra alt, hvad der involverede den nu forladte bruger. Dette design giver den bedste brugeroplevelse, men er den sværeste at skalere, vigtigst af alt, fordi det er nødvendigt at forberede sig på alle mulige exit-scenarier, herunder alle mulige exit-scenarier for alle potentielle nye puljer. Skala kunne dog opnås med en endnu ikke-navngivet potentiel Bitcoin-protokolopgradering for at sikre, at reglerne fra den forrige betalingspulje overføres til enhver ny betalingspulje.

Rubin mener dog, at denne anden løsning er upraktisk og foretrækker at gå efter noget imellem den første og anden løsning: nogle deltagere modtager straks deres mønter til en adresse, de vælger, andre deltagere får deres mønter sendt til en ny betalingspulje. Dette design giver en mindre ideel brugeroplevelse, men vil skalere bedre, og den potentielle OP_CHECKTEMPLATEVERIFY-protokolopgradering vil hjælpe med at forenkle designet og øge skalaen endnu mere. (Udgange vil ske gennem træbetalinger; disse typer betalinger udforskes nærmere i denne artikel.)

(Der er flere kompromiser mellem den anden og den tredje løsning, men detaljerne i alle fordele og ulemper er uden for denne artikels anvendelsesområde; læs bitcoin-dev mailingliste diskussion for detaljer.)

For at se hvad det betyder, når resterende mønter sendes til en ny betalingspulje, lad os sige, at Alice, Bob og Carol vælger den anden mulighed, hvor alle resterende mønter sendes til en ny betalingspulje. Hvis Alice i dette design går ud af den første betalingspulje, sendes tre mønter til en adresse, hun vælger, mens de andre tre mønter sendes til en ny betalingspulje mellem Bob og Carol. Alice på det tidspunkt har enekontrol over sine egne mønter igen, mens ikke så meget har ændret sig for Bob og Carol. De to kan stadig samarbejde om at bruge de tre resterende mønter, uanset hvad de ønsker, eller en af ​​dem kan forlade ensidigt, som Alice havde gjort før.

Hvis Bob derefter går ud ensidigt fra den anden betalingspulje, sender han to mønter til en adresse efter eget valg og en mønt til en endnu nyere betalingspulje (den tredje) med kun Carol tilbage. (Selvfølgelig ville et design, hvor denne sidste betalingspulje erstattes med en adresse, som Carol valgte, i dette forenklede eksempel faktisk give mere mening, men det er en implementeringsdetalje.)

Den vigtige takeaway er, at deltagerne i en betalingspulje kan samarbejde om at foretage enhver form for betaling fra den pulje, de ønsker, mens en af ​​dem når som helst kan gå ud med deres egne mønter og lade andre deltagere kontrollere deres.

Sætte betalingen i betalingspuljen

Så vi har konstateret, at alle deltagere kan trække deres saldo individuelt fra en betalingspulje eller – hvis de alle er enige – bruge fra puljen. Det er denne anden mulighed, der faktisk muliggør noget smart: betalingspoolen kan være dynamisk. Så længe alle deltagere er enige, kan de ikke bare betale deres penge tilbage eller betale andre (som Julian), men de kan gøre noget endnu mere interessant. De kan flytte deres midler til nyere versioner af betalingspuljen med forskellige designs.

Dette lader for eksempel nogen af ​​dem bruge fra puljen.

Lad os sige, at Alice køber en ny bil og vil betale for den med en bitcoin. Alice, Bob og Carol kunne derefter oprette en transaktion fra betalingspuljen, der sender en mønt til bilforhandleren og sender de resterende fem mønter til en ny betalingspulje, der ser ud som den første, undtagen denne gang kan Alice kun gå ud fra den ensidigt med to mønter, en mindre end før.

Transaktionen lignede i mellemtiden enhver anden almindelig Bitcoin-transaktion. Bilforhandleren (eller blockchain-spionerne) kan konkludere, at Alice ejede alle seks mønter og simpelthen brugte en til at købe bilen og holdt de andre fem som forandring. De ville ikke have nogen idé om, at nogle af mønterne tilhører Bob og Carol, eller at de overhovedet var involveret i transaktionen.

Næste gang, når Bob foretager en betaling, og Alice og Carol samarbejder, foretages den fra den samme betalingspulje, der igen ser ud som en almindelig Bitcoin-transaktion til omverdenen. I den resulterende iteration af betalingspuljen kan Bob afslutte med en mønt i stedet for to. I mellemtiden har de samme blockchain-spioner måske troet, at Alice foretog en betaling igen og forvirrede dem yderligere. (Og selvom blockchain-spionerne på en eller anden måde ville finde ud af, at adressen virkelig er en betalingspulje mellem Alice, Bob og Carol, kunne de stadig ikke fortælle, hvem af de tre der foretog den seneste betaling.)

Hver gang Alice, Bob eller Carol bruger mønter, kan transaktionen stamme fra nogen af ​​dem, og ingen uden for betalingspuljen kan se forskellen.

Betalingspuljer tillader ikke kun udgifter. Hvis Alice vil supplere sin “saldo” i betalingspuljen, kan hun også gøre dette. Alice, Bob og Carol ville i dette tilfælde samarbejde om at flytte de nuværende fem mønter til en ny Taproot-adresse, hvortil Alice i samme transaktion ville sende en ekstra mønt fra en af ​​hendes egne (individuelle) adresser. Den nye Taproot-adresse ville igen indeholde seks mønter, hvoraf tre tilhører Alice, hvilket afspejles i hendes ensidige exitmulighed.

På samme måde kunne helt nye brugere også deltage i betalingspuljen. Hvis Alice, Bob og Carol er enige om at lade Dave deltage, samarbejder de tre med Dave for at skabe en transaktion, der sender betalingspuljen midler sammen med Daves nye mønter til en ny betalingspulje, der er designet til også at lade Dave deltage – og afslutte hvis han ville vælge det.

Der er desuden mulighed for deltagere i betalingspuljen at betale hinanden. Hvis Alice for eksempel ville betale Bob en mønt, kunne de tre samarbejde om at sende midlerne til en ny betalingspulje, hvor Alice får en mønt trukket fra sin saldo, og Bob får en mønt tilføjet. På blockchain ser det igen ud som en regelmæssig betaling, og blockchain-spioner ville ikke have nogen idé om, hvem der betalte hvem eller hvor meget. (Det er værd at påpege, at Dave på samme måde kunne være kommet ind i puljen ved at modtage en intern betaling fra en af ​​de eksisterende deltagere.)

Med lidt ekstra kompleksitet (og ideelt set med mindst en ekstra Bitcoin-protokolopgradering som Noinput), kunne overførsler endda også gennemføres uden for kæden. Når Alice betaler Bob, ville alle deltagere i dette tilfælde oprette en transaktion, der bruger midler til en ny betalingspulje på samme måde, men denne transaktion deles kun mellem dem – ikke udsendes til netværket (medmindre nogen nogensinde prøver at snyde). På denne måde kunne Alice, Bob og Carol fortsætte med at opdatere deres balance “internt” og endda lade Dave komme ind i puljen på et eller andet tidspunkt. Når de alle er enige om at lukke puljen, kan de oprette en endelig transaktion, der bruges fra den oprindelige betalingspulje, og tildele hver deres seneste saldo.

I lighed med en ældre idé kendt som Channel Factories kunne disse typer betalingspuljer i sidste ende endda bruges til at være vært for lynkanaler, hvælvinger eller andre Layer Two-protokoller. Dette kan tilbyde potentialet til at “indpakke” enhver form for ekstra protokollag i sådanne puljer og dermed skjule al deres kompleksitet i identiske og regelmæssige udseende transaktioner.