Denne artikkelen handler om et teknologisk konsept basert på den foreslåtte oppgraderingen av Taproot-protokollen. Hvis du ennå ikke er kjent med det grunnleggende om hvordan Taproot fungerer, anbefales det at du først leser denne forklareren.
taproot, en potensiell oppgradering til Bitcoin-protokollen som først ble foreslått av Bitcoin Core-bidragsyter Gregory Maxwell, er i sine sene utviklingsstadier. Teknologien består av en smart kombinasjon av kryptotriks som lar brukere skjule komplekse smarte kontrakter i transaksjoner som ser vanlige ut – kompleksiteten avsløres bare hvis partene i en kontrakt er lite samarbeidsvillige.
Ved å utnytte denne ideen har Bitcoin Core-bidragsytere inkludert (men ikke begrenset til) Jeremy Rubin, Antoine Riard, Gleb Naumenko og Gregory Maxwell selv spekulert i et generelt konsept referert til som betalingspuljer, joinpools eller coinpools. Disse bassengene – vi vil fortsette å kalle dem betalingspuljer foreløpig – vil la grupper av brukere dele eierskapet til de samme myntene (teknisk: UTXO-er) som registrert på Bitcoin-blokkjeden, samtidig som de lar noen av disse brukerne foreta (eller motta) betalinger med dem. Ettersom gruppen og dens individuelle medlemmer "gjemmer seg" i en Taproot-struktur, nyter de alle mer privatliv, smart kontraktsfleksibilitet og andre fordeler ... og de kan til og med nyte godt av disse fordelene utenfor kjeden, noe som gjør betalingspuljer til en ny Layer Two-løsning.
Selv om designspesifikasjonene varierer litt fra det ene betalingspuljeforslaget til det neste, er det generelle konseptet det samme. Her er den grunnleggende ideen...
Deler en mynt
For det første, for å opprette en betalingspool, kombinerer brukere sine (brøkdeler av) mynter ved å samle dem i en taproot-adresse som deles mellom dem. Så la oss si at Alice eier tre mynter, Bob eier to mynter og Carol eier én mynt, totalt seks. Sammen lager de en transaksjon som sender disse myntene til den delte adressen, noe som gjør det til en betalingspool med seks mynter.
På blokkjeden ser betalingspooladressen ut som en vanlig Bitcoin-adresse, som nå inneholder seks mynter. Men under overflaten brukte Alice, Bob og Carol på en smart måte Taproot for å sikre at hver av dem fortsatt har kontroll over sin egen andel av mynter i betalingspuljen. Alice kan når som helst kreve tre mynter fra adressen, Bob kan når som helst kreve to og Carol én.
Dette er fordi det kun er to hovedalternativer for å bruke mynter fra adressen.
Det første alternativet er å bruke direkte fra adressen, i tekniske termer Taproot-nøkkelbanen. Dette krever samarbeid (det vil si: kryptografiske signaturer) fra alle tre deltakerne. Hvis Alice, Bob og Carol alle er enige, kan de seks myntene brukes slik de vil, og dette vil se ut som enhver annen vanlig transaksjon på Bitcoin-nettverket. Trioen kan for eksempel bestemme seg for å sende sine respektive saldoer tilbake til individuelle adresser: tre for Alice, to for Bob og en for Carol. Men hvis de hadde valgt det, kunne de også samarbeide om å donere alle seks myntene til Julian, eller bruke dem på en annen måte de måtte bli enige om. Det viktige er at alle tre må delta, så ingens saldo blir brukt uten hans eller hennes eget samarbeid.
Det andre hovedalternativet består faktisk av flere underalternativer. Før de sendte myntene sine til betalingspoolen, gjemte Alice, Bob og Carol noe i det kryptografiske treet bak Taproot-adressen: de inkluderte alternative måter å sende midler fra betalingspuljen på. (Foreløpig kan dette realiseres ved å la alle tre deltakerne forhåndssignere transaksjoner fra disse banene, noe som vil kreve noe kompleksitet for å sette opp alle alternativene og ikke skaleres særlig godt; foreslåtte protokolloppgraderinger kan potensielt gjøre dette enklere i fremtiden .)
Hvis en av deltakerne ville velge å bruke myntene i betalingspuljen gjennom en alternativ Taproot-bane, vil de vanligvis sende et beløp som tilsvarer den deltakerens saldo til en adresse de selv velger, for eksempel en individuell adresse som de kontrollerer. (I Alices tilfelle, tre mynter til hennes egen adresse, i Bobs tilfelle to til adressen hans og i Carols tilfelle en.)
Ved å bruke denne alternative banen blir de resterende myntene automatisk brukt også. Dette kan gjøres på flere måter avhengig av utformingen av betalingspoolen, og tilbyr ulike avveininger med hensyn til kompleksitet og skalerbarhet.
Den enkleste løsningen er å sende hver andre deltaker sin andel av mynter også, til en adresse de selv velger. Med andre ord: Hvis én bruker går ut av bassenget, går alle ut av bassenget.
En annen løsning, foretrukket av Riard og Naumenko, er å sende alle de gjenværende myntene til en nytt betalingspool, som ser nøyaktig ut som den første betalingspoolen, bare fjernet fra alt som involverte den nå avsluttede brukeren. Denne designen gir den beste brukeropplevelsen, men er den vanskeligste å skalere, viktigst av alt fordi det er nødvendig å forberede seg på alle mulige exit-scenarier, inkludert alle mulige exit-scenarier for alle potensielle nye bassenger. Skalering kan imidlertid oppnås med en potensiell Bitcoin-protokolloppgradering som ennå ikke er navngitt for å sikre at reglene fra den forrige betalingspoolen overføres til enhver ny betalingspool.
Rubin mener imidlertid at denne andre løsningen er upraktisk, og foretrekker å gå for noe mellom den første og andre løsningen: noen deltakere mottar umiddelbart myntene sine til en adresse de selv velger, andre deltakere får myntene sendt til en ny betalingspool. Denne utformingen gir en mindre ideell brukeropplevelse, men vil skalere bedre, og den potensielle OP_CHECKTEMPLATEVERIFY-protokolloppgraderingen vil bidra til å forenkle designet og øke skalaen enda mer. (Utganger vil skje gjennom Tree Payments; disse typer betalinger utforskes lenger inn denne artikkelen.)
(Det er flere avveininger mellom den andre og tredje løsningen, men detaljene om alle fordeler og ulemper er utenfor rammen av denne artikkelen; les bitcoin-dev-postlistediskusjon for detaljer.)
For å se hva det betyr når gjenværende mynter sendes til en ny betalingspool, la oss si at Alice, Bob og Carol velger det andre alternativet, der alle gjenværende mynter sendes til en ny betalingspool. Hvis Alice i dette designet forlater den første betalingspoolen, sendes tre mynter til en adresse hun selv velger, mens de tre andre myntene sendes til en ny betalingspool mellom Bob og Carol. Alice har på det tidspunktet enekontroll over sine egne mynter igjen, mens ikke så mye har endret seg for Bob og Carol. De to kan fortsatt samarbeide for å bruke de tre gjenværende myntene slik de ønsker, eller en av dem kan gå ut ensidig, slik Alice hadde gjort før.
Hvis Bob så går ut ensidig fra den andre betalingspoolen, sender han to mynter til en adresse han selv velger, og en mynt til en enda nyere betalingspool (den tredje) med bare Carol igjen. (Selvfølgelig, i dette forenklede eksemplet, ville et design der denne siste betalingspoolen erstattes med en adresse etter Carols valg i virkeligheten være mer fornuftig, men det er en implementeringsdetalj.)
Den viktige takeawayen er at deltakere i en betalingspool kan samarbeide for å foreta hvilken som helst type betaling fra bassenget de ønsker, mens hvem som helst av dem når som helst kan gå ut med sine egne mynter, slik at andre deltakere har kontroll over sine.
Sette betalingen i betalingspuljen
Så vi har etablert at alle deltakere individuelt kan ta ut saldoen sin fra en betalingspool, eller – hvis alle er enige – bruke penger fra poolen. Det er dette andre alternativet som faktisk muliggjør noe smart: betalingspoolen kan være dynamisk. Så lenge alle deltakerne er enige, kan de ikke bare betale tilbake pengene sine selv, eller betale andre (som Julian), men de kan gjøre noe enda mer interessant. De kan flytte pengene sine til nyere versjoner av betalingspuljen, med forskjellige design.
Dette lar for eksempel en av dem bruke fra bassenget.
La oss si at Alice kjøper en ny bil og ønsker å betale for den med én bitcoin. Alice, Bob og Carol kan deretter opprette en transaksjon fra betalingspuljen som sender én mynt til bilforhandleren, og sender de resterende fem myntene til en nytt betalingspool som ser lik ut som den første, bortsett fra at Alice denne gangen bare kan gå ut av den ensidig med to mynter, én mindre enn før.
Transaksjonen så i mellomtiden ut som enhver annen vanlig Bitcoin-transaksjon. Bilforhandleren (eller blokkjedespioner) kan konkludere med at Alice eide alle seks myntene og bare brukte en til å kjøpe bilen, og beholdt de fem andre som bytte. De ville ikke ha noen anelse om at noen av myntene tilhører Bob og Carol, eller at de i det hele tatt var involvert i transaksjonen.
Neste gang, når Bob foretar en betaling og Alice og Carol samarbeider, er den laget fra den samme betalingspoolen, som igjen ser ut som en vanlig Bitcoin-transaksjon for omverdenen. I den resulterende iterasjonen av betalingspuljen kan Bob avslutte med én mynt i stedet for to. I mellomtiden kan de samme blokkjedespionene ha trodd at Alice foretok en betaling igjen, og forvirret dem ytterligere. (Og selv om blokkjedespionene på en eller annen måte skulle finne ut at adressen virkelig er en betalingspool mellom Alice, Bob og Carol, kunne de fortsatt ikke fortelle hvem av de tre som foretok den siste betalingen.)
Hver gang Alice, Bob eller Carol bruker mynter, kan transaksjonen ha kommet fra en av dem, og ingen utenfor betalingspuljen kan se forskjellen.
Betalingspuljer tillater ikke bare utgifter. Hvis Alice ønsker å fylle på "saldoen" i betalingspuljen, kan hun også gjøre dette. Alice, Bob og Carol ville i dette tilfellet samarbeide for å flytte de nåværende fem myntene til en ny Taproot-adresse, som Alice i samme transaksjon ville sende en ekstra mynt til fra en av hennes egne (individuelle) adresser. Den nye Taproot-adressen vil igjen inneholde seks mynter, hvorav tre tilhører Alice, som gjenspeiles i hennes ensidige utgangsalternativ.
På samme måte kan helt nye brukere også bli med i betalingspoolen. Hvis Alice, Bob og Carol blir enige om å la Dave delta, samarbeider de tre med Dave for å lage en transaksjon som sender betalingspuljens midler sammen med Daves nye mynter til en ny betalingspool, designet for å la Dave også delta – og avslutte hvis han velger det.
Videre er det mulighet for deltakere i betalingspuljen til å betale hverandre. Hvis Alice for eksempel ville betale Bob én mynt, kunne de tre samarbeide for å sende midlene til en ny betalingspool der Alice får en mynt trukket fra saldoen og Bob har lagt til en mynt. På blokkjeden, igjen, ville det se ut som en vanlig betaling, og blokkjedespioner ville ikke ha noen anelse om hvem som betalte hvem, eller hvor mye. (Det er verdt å påpeke at Dave kunne ha gått inn i bassenget på lignende måte ved å motta en intern betaling fra en av de eksisterende deltakerne.)
Med litt ekstra kompleksitet (og ideelt sett med minst én ekstra Bitcoin-protokolloppgradering som Ingen inngang), kan overføringer også gjennomføres utenfor kjeden. Når Alice betaler Bob, vil alle deltakerne i dette tilfellet opprette en transaksjon som bruker midler til en ny betalingspool på samme måte, men denne transaksjonen vil bare bli delt mellom dem - ikke kringkastet til nettverket (med mindre noen noen gang prøver å jukse). På denne måten kunne Alice, Bob og Carol fortsette å oppdatere balansen "internt", og til og med slippe Dave inn i bassenget på et tidspunkt. Når de alle er enige om å stenge bassenget, kan de opprette en endelig transaksjon som bruker fra den opprinnelige betalingspoolen, og tildele hver sin siste saldo.
Ligner på en eldre idé kjent som Kanalfabrikker, kan disse typene betalingspooler til og med brukes til å være vert for Lightning-kanaler, hvelv eller andre Layer Two-protokoller. Dette kan tilby potensialet til å "pakke inn" alle typer ekstra protokolllag i slike bassenger, og dermed skjule all kompleksiteten deres i identiske og regelmessige transaksjoner.