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 virker, anbefales det, at du først læser denne forklarer.
pælerod, en potentiel opgradering til Bitcoin-protokollen, som først blev foreslået af Bitcoin Core-bidragyderen Gregory Maxwell, er i sine sene udviklingsstadier. Teknologien består af en smart kombination af krypto-tricks, der ville lade brugere skjule komplekse smarte kontrakter i transaktioner med almindeligt udseende - kompleksiteten afsløres kun, hvis parterne i en kontrakt ikke er samarbejdsvillige.
Ved at udnytte denne idé har Bitcoin Core-bidragydere inklusive (men ikke begrænset til) Jeremy Rubin, Antoine Riard, Gleb Naumenko og Gregory Maxwell selv spekuleret i et generelt koncept, der omtales som betalingspuljer, joinpools eller møntpuljer. Disse puljer - vi vil holde os til at kalde dem betalingspuljer indtil videre - ville lade grupper af brugere dele ejerskabet af de samme mønter (teknisk: UTXO'er) som registreret på Bitcoin blockchain, mens de lader enhver 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 designspecifikationerne varierer en smule fra det ene betalingspuljeforslag til det næste, er det generelle koncept det samme. Her er den grundlæggende idé...
Deler en mønt
For det første, for at oprette en betalingspulje, kombinerer brugere deres (brøkdele af) mønter ved at samle dem i en Taproot-adresse, der deles mellem dem. Så lad os sige, at Alice ejer tre mønter, Bob ejer to mønter og Carol ejer en mønt, i alt seks. Sammen skaber de en transaktion, der sender disse mønter til den fælles adresse, hvilket gør det til en betalingspulje med seks mønter.
På blockchain ligner betalingspuljeadressen en almindelig Bitcoin-adresse, der nu rummer seks mønter. Men under overfladen brugte Alice, Bob og Carol smart Taproot til at sikre, at hver af dem forbliver i kontrol over deres egen andel af mønter i betalingspuljen. Alice kan på et hvilket som helst tidspunkt gøre krav på tre mønter fra adressen, Bob kan til enhver tid gøre krav på 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, i tekniske termer Taproot-nøglestien. Dette kræver samarbejde (det vil sige: kryptografiske signaturer) fra alle tre deltagere. Hvis Alice, Bob og Carol alle er enige, kan de seks mønter bruges som de vil, og dette vil ligne enhver anden almindelig transaktion på Bitcoin-netværket. Trioen kan for eksempel beslutte at sende deres respektive saldi tilbage til individuelle adresser: tre til Alice, to til Bob og en til Carol. Men hvis de havde valgt det, kunne de også samarbejde om at donere alle seks mønter til Julian, eller bruge dem på en anden måde, de måtte blive enige om. Det vigtige er, at de alle tre skal deltage, så ingens saldo bliver brugt uden hans eller hendes eget samarbejde.
Den anden hovedmulighed består faktisk af flere undermuligheder. Før de sendte deres mønter til betalingspuljen, gemte Alice, Bob og Carol noget i det kryptografiske træ bag Taproot-adressen: de inkluderede alternative måder at sende penge fra betalingspuljen på. (I øjeblikket kan dette realiseres ved at lade alle tre deltagere forhåndssignere transaktioner fra disse stier, hvilket ville kræve en vis kompleksitet at konfigurere alle mulighederne og ikke skaleres særlig godt; foreslåede protokolopgraderinger kan potentielt gøre dette lettere i fremtiden .)
Hvis en af deltagerne ville vælge at bruge mønterne i betalingspuljen gennem en alternativ Taproot-sti, ville de typisk sende et beløb svarende til den pågældende deltagers saldo til en adresse efter eget valg, som en individuel adresse, som de kontrollerer. (I Alices tilfælde tre mønter til hendes egen adresse, i Bobs tilfælde to til hans adresse og i Carols tilfælde en.)
Ved at bruge denne alternative vej bliver de resterende mønter også brugt automatisk. Dette kan gøres på flere måder afhængigt af betalingspuljens design, hvilket giver forskellige afvejninger med hensyn til kompleksitet og skalerbarhed.
Den enkleste løsning er også at sende hver anden deltager deres andel af mønter til en adresse efter eget valg. Med andre ord: Hvis én bruger forlader poolen, forlader alle poolen.
En anden løsning, som Riard og Naumenko foretrækker, er at sende alle de resterende mønter til en ny betalingspulje, der ligner den første betalingspulje, blot fjernet fra alt, der involverede den nu forladte bruger. Dette design giver den bedste brugeroplevelse, men er det sværeste at skalere, vigtigst af alt fordi det er nødvendigt at forberede sig på alle mulige exit-scenarier, inklusive 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 tidligere betalingspulje overføres til enhver ny betalingspulje.
Rubin mener dog, at denne anden løsning er upraktisk og foretrækker at gå efter noget mellem den første og anden løsning: nogle deltagere modtager straks deres mønter til en adresse efter eget valg, andre deltagere får deres mønter sendt til en ny betalingspulje. Dette design tilbyder 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 ville ske gennem Tree Payments; disse typer betalinger undersøges længere ind denne artikel.)
(Der er flere afvejninger mellem den anden og tredje løsning, men detaljerne om alle fordele og ulemper er uden for denne artikels omfang; 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 forlader den første betalingspulje, sendes tre mønter til en adresse efter hendes valg, mens de tre andre mønter sendes til en ny betalingspulje mellem Bob og Carol. Alice har på det tidspunkt 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, som de ønsker, eller en af dem kan forlade dem ensidigt, som Alice havde gjort før.
Hvis Bob så ensidigt forlader 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 i dette forenklede eksempel et design, hvor denne sidste betalingspulje erstattes med en adresse efter Carols valg, i virkeligheden give mere mening, men det er en implementeringsdetalje.)
Den vigtige takeaway er, at deltagere i en betalingspulje kan samarbejde om at foretage enhver form for betaling fra den pulje, de ønsker, mens enhver af dem til enhver tid kan afslutte med deres egne mønter, så andre deltagere har kontrol over deres.
Sætter betalingen i betalingspuljen
Så vi har fastslået, at alle deltagere individuelt kan hæve deres saldo fra en betalingspulje eller - hvis de alle er enige - bruge dem fra puljen. Det er denne anden mulighed, der faktisk muliggør noget smart: betalingspuljen kan være dynamisk. Så længe alle deltagere er enige, kan de ikke bare betale sig selv deres penge tilbage eller betale andre (som Julian), men de kan gøre noget endnu mere interessant. De kan flytte deres penge til nyere versioner af betalingspuljen med forskellige designs.
Dette lader for eksempel enhver af dem bruge fra poolen.
Lad os sige, at Alice køber en ny bil og vil betale for den med én 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 det samme ud som den første, bortset fra at Alice denne gang kun kan forlade 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 blot brugte en til at købe bilen og beholdt de fem andre som byttepenge. 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, er den lavet fra den samme betalingspulje, som igen ligner en almindelig Bitcoin-transaktion for omverdenen. I den resulterende iteration af betalingspuljen kan Bob afslutte med én mønt i stedet for to. I mellemtiden kan de samme blockchain-spioner have troet, at Alice foretog en betaling igen, hvilket 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 se, hvem af de tre, der foretog den seneste betaling.)
Hver gang Alice, Bob eller Carol bruger mønter, kan transaktionen være kommet fra en af dem, og ingen uden for betalingspuljen kan se forskel.
Betalingspuljer tillader ikke kun forbrug. Hvis Alice ønsker at fylde sin "saldo" op 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 sine egne (individuelle) adresser. Den nye Taproot-adresse ville igen indeholde seks mønter, hvoraf tre tilhører Alice, som afspejlet i hendes ensidige exit-mulighed.
På samme måde kunne helt nye brugere også deltage i betalingspuljen. Hvis Alice, Bob og Carol bliver enige om at lade Dave deltage, samarbejder de tre med Dave om at skabe en transaktion, der sender betalingspuljens midler sammen med Daves nye mønter til en ny betalingspulje, designet til også at lade Dave deltage - og afslutte hvis han ville det.
Desuden er der mulighed for, at deltagere i betalingspuljen kan betale hinanden. Hvis Alice for eksempel ville betale Bob én 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 har tilføjet en mønt. På blockchain ville det igen ligne en almindelig 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å lignende måde kunne være kommet ind i puljen ved at modtage en intern betaling fra en af de eksisterende deltagere.)
Med en lille smule ekstra kompleksitet (og ideelt set med mindst én ekstra Bitcoin-protokolopgradering som Ingen input), kan 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 vil kun blive delt mellem dem - ikke udsendt til netværket (medmindre nogen nogensinde forsøger at snyde). På denne måde kunne Alice, Bob og Carol blive ved med at opdatere deres balance "internt" og endda lade Dave komme i poolen på et tidspunkt. Når de alle er enige om at lukke puljen, kan de oprette en endelig transaktion, der bruger fra den oprindelige betalingspulje, og tildele hver deres seneste saldo.
Svarende til en ældre idé kendt som Kanalfabrikker, kunne disse typer betalingspuljer i sidste ende endda bruges til selv at være vært for Lightning-kanaler, vaults eller andre Layer Two-protokoller. Dette kan give mulighed for at "indpakke" enhver form for yderligere protokollag i sådanne puljer, og dermed skjule al deres kompleksitet i identiske og regelmæssigt udseende transaktioner.