Denne artikkelen handler om et teknologisk konsept basert på den foreslåtte Taproot-protokolloppgraderingen. Hvis du ennå ikke er kjent med det grunnleggende om hvordan Taproot fungerer, anbefales det at du først leser denne forklaringen.

Taproot, en potensiell oppgradering av Bitcoin-protokollen som først ble foreslått av Bitcoin Core-bidragsyter Gregory Maxwell, er i sine sene stadier av utvikling. Teknologien består av en smart kombinasjon av krypto-triks som lar brukere skjule komplekse smarte kontrakter i transaksjoner med vanlig utseende – kompleksiteten blir bare avslørt hvis kontraktspartene ikke er samarbeidsvillige.

Bitcoin Core-bidragsytere, inkludert (men ikke begrenset til) Jeremy Rubin, Antoine Riard, Gleb Naumenko og Gregory Maxwell selv, har utnyttet denne ideen og har spekulert i et generelt konsept referert til som betalingsbassenger, joinpools eller myntebassenger. Disse bassengene – vi holder fast ved å kalle dem betalingsbassenger for nå – lar grupper av brukere dele eierskap av de samme myntene (teknisk: UTXOs) som registrert i Bitcoin blockchain, mens de lar noen av disse brukerne foreta (eller motta) betalinger med dem. Etter hvert som gruppen og dens individuelle medlemmer “gjemmer seg” i en Taproot-struktur, nyter alle av dem mer privatliv, smart kontraktsfleksibilitet og andre fordeler … og de kan til og med nyte godt av disse fordelene utenfor kjeden, noe som gjør betalingsbassenger til en ny Layer Two-løsning.

Selv om designspesifikasjoner varierer litt fra det ene betalingsbassengforslaget til det neste, er det generelle konseptet det samme. Her er grunnideen …

Dele en mynt

For det første, for å opprette en betalingsmasse, kombinerer brukere sine (brøkdeler av) mynter ved å samle dem i en Taproot-adresse som deles mellom dem. La oss si at Alice eier tre mynter, Bob eier to mynter og Carol eier en mynt, til sammen seks. Sammen oppretter de en transaksjon som sender disse myntene til den delte adressen, noe som gjør det til en betalingsmasse med seks mynter.

På blockchain ser betalingsbassengadressen ut som en vanlig Bitcoin-adresse, som nå har seks mynter. Men under overflaten brukte Alice, Bob og Carol smart Taproot for å sikre at hver av dem fortsatt har kontroll over sin egen andel mynter i betalingsbassenget. Alice kan når som helst kreve tre mynter fra adressen, Bob kan når som helst kreve to og Carol en.

Dette er fordi det bare er to hovedalternativer for å bruke mynter fra adressen.

Det første alternativet er å bruke direkte fra adressen, teknisk sett Taproot-nøkkelbanen. Dette krever samarbeid (det vil si kryptografiske signaturer) fra alle de tre deltakerne. Hvis Alice, Bob og Carol alle er enige, kan de seks myntene brukes slik de vil, og dette vil se ut som alle andre vanlige transaksjoner 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 velger det, kan de også samarbeide om å donere alle seks myntene til Julian, eller bruke den på noen annen måte de måtte bli enige om. Det viktige er at alle tre av dem trenger å delta, slik at ingen balanserer uten hans eller hennes eget samarbeid.

Det andre hovedalternativet består faktisk av flere underalternativer. Før Alice, Bob og Carol sendte myntene sine til betalingsbassenget, skjulte de noe i det kryptografiske treet bak Taproot-adressen: de inkluderte alternative måter å sende midler fra betalingsbassenget. (For øyeblikket kan dette realiseres ved at alle tre deltakerne forhåndsignerer transaksjoner fra disse banene, noe som vil kreve litt kompleksitet for å sette opp alle alternativene og ikke skaleres veldig bra. Foreslåtte protokolloppgraderinger kan potensielt gjøre dette lettere i fremtiden .)

Hvis en av deltakerne velger å bruke myntene i betalingsmassen gjennom en alternativ Taproot-bane, vil de vanligvis sende et beløp som tilsvarer deltakerens saldo til en adresse de velger, som en individuell adresse de kontrollerer. (I Alice sitt tilfelle tre mynter til hennes egen adresse, i Bobs tilfelle to til hans adresse og i Carol sin tilfelle en.)

Ved å bruke denne alternative banen blir de gjenværende myntene automatisk brukt også. Dette kan gjøres på flere måter, avhengig av utformingen av betalingsmassen, og tilbyr forskjellige kompromisser når det gjelder kompleksitet og skalerbarhet..

Den enkleste løsningen er å sende alle andre deltakere også sin andel av mynter, til en adresse de velger. Med andre ord: hvis en bruker går ut av bassenget, kommer alle ut av bassenget.

En annen løsning, foretrukket av Riard og Naumenko, er å sende alle gjenværende mynter til en ny betalingsbasseng, som ser ut som den første betalingsbassenget, bare fjernet fra alt som involverte den nå utgitte 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 utgangsscenarier, inkludert alle mulige utgangsscenarier for alle potensielle nye bassenger. Skala kan imidlertid oppnås med en ennå ikke utnevnt potensiell Bitcoin-protokolloppgradering for å sikre at reglene fra forrige betalingsmasse overføres til en hvilken som helst ny betalingsmasse.

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 velger, andre deltakere får myntene sine sendt til en ny betalingsbasseng. Denne designen gir en mindre ideell brukeropplevelse, men vil bli bedre, og den potensielle OP_CHECKTEMPLATEVERIFY-protokolloppgraderingen vil bidra til å forenkle designet og øke skalaen enda mer. (Utganger vil skje gjennom Tree Payments; denne typen betalinger blir utforsket nærmere i denne artikkelen.)

(Det er flere kompromisser mellom den andre og den tredje løsningen, men detaljene til alle fordeler og ulemper ligger utenfor omfanget av denne artikkelen. Les bitcoin-dev adresseliste diskusjon for detaljer.)

For å se hva det betyr når gjenværende mynter blir sendt til en ny betalingsmasse, la oss si at Alice, Bob og Carol velger det andre alternativet, der alle gjenværende mynter blir sendt til en ny betalingsmasse. Hvis Alice i dette designet går ut av den første betalingsmassen, blir tre mynter sendt til en adresse du velger, mens de andre tre myntene blir sendt til en ny betalingsmasse mellom Bob og Carol. Alice på det tidspunktet har kontroll over sine egne mynter igjen, mens ikke så mye har endret seg for Bob og Carol. De to kan fremdeles samarbeide om å bruke de tre gjenværende myntene, men de vil, eller en av dem kan gå ut ensidig, slik Alice hadde gjort før.

Hvis Bob deretter går ut ensidig fra den andre betalingsmassen, sender han to mynter til en adresse du velger, og en mynt til en enda nyere betalingsmasse (den tredje) med bare Carol igjen. (Selvfølgelig, i dette forenklede eksemplet, ville et design der denne siste betalingsmassen erstattes med en adresse som Carol valgte, faktisk være mer fornuftig, men det er en detalj for implementeringen.)

Den viktige takeawayen er at deltakere i en betalingsbasseng kan samarbeide om å foreta en hvilken som helst type betaling fra bassenget de ønsker, mens en av dem når som helst kan gå ut med sine egne mynter, slik at andre deltakere har kontroll over sine.

Sette betalingen i betalingsbassenget

Så vi har slått fast at alle deltakere kan trekke saldoen hver for seg fra en betalingsmasse, eller – hvis de er enige – bruke penger i bassenget. Det er dette andre alternativet som faktisk muliggjør noe smart: betalingsmassen kan være dynamisk. Så lenge alle deltakerne er enige, kan de ikke bare betale tilbake pengene sine, eller betale andre (som Julian), men de kan gjøre noe enda mer interessant. De kan flytte midlene til nyere versjoner av betalingsbassenget, med forskjellige design.

Dette lar for eksempel noen av dem bruke fra bassenget.

La oss si at Alice kjøper en ny bil, og ønsker å betale for den med en bitcoin. Alice, Bob og Carol kunne da opprette en transaksjon fra betalingsmassen som sender en mynt til bilforhandleren, og sender de resterende fem myntene til en ny betalingsmasse som ser ut som den første, bortsett fra denne gangen kan Alice bare gå ut fra den ensidig med to mynter, en mindre enn før.

Transaksjonen så imidlertid ut som alle andre vanlige Bitcoin-transaksjoner. Bilforhandleren (eller blockchain spioner) kan konkludere med at Alice eide alle de seks myntene og bare brukte en til å kjøpe bilen, og holdt de andre fem som forandring. De hadde ingen 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, blir den gjort fra samme betalingsmasse, som igjen ser ut som en vanlig Bitcoin-transaksjon til omverdenen. I den resulterende iterasjonen av betalingsmassen kan Bob gå ut med en mynt i stedet for to. I mellomtiden kan de samme blockchain-spionene ha trodd Alice betalte igjen, og forvirret dem ytterligere. (Og selv om blockchain-spionene på en eller annen måte ville finne ut at adressen virkelig er en betalingsmasse mellom Alice, Bob og Carol, kunne de fortsatt ikke fortelle hvem av de tre som betalte den siste betalingen.)

Hver gang Alice, Bob eller Carol bruker mynter, kan transaksjonen ha kommet fra noen av dem, og ingen utenfor betalingsmassen kan se forskjellen.

Betalingsbassenger tillater ikke bare å bruke penger. Hvis Alice vil fylle på “saldoen” i betalingsbassenget, kan hun også gjøre dette. Alice, Bob og Carol vil i dette tilfellet samarbeide om å flytte de fem nåværende myntene til en ny Taproot-adresse, som Alice i samme transaksjon vil 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, noe som gjenspeiles i hennes ensidige exit-alternativ.

På samme måte kan helt nye brukere også bli med i betalingsmassen. Hvis Alice, Bob og Carol blir enige om å la Dave delta, samarbeider de tre med Dave for å opprette en transaksjon som sender betalingsmassene sammen med Daves nye mynter til en ny betalingsbasseng, designet for å også la Dave delta – og gå ut hvis han velger det.

Videre er det muligheten for deltakere i betalingsmassen å betale hverandre. Hvis Alice for eksempel ville betale Bob en mynt, kunne de tre samarbeide om å sende midlene til en ny betalingsbasseng der Alice har en mynt trukket fra saldoen og Bob har en mynt lagt til. På blockchain vil det igjen se ut som en vanlig betaling, og blockchain-spioner ville ikke ane hvem som betalte hvem eller hvor mye. (Det er verdt å påpeke at Dave på en lignende måte kunne ha kommet inn i bassenget ved å motta en intern betaling fra en av de eksisterende deltakerne.)

Med litt ekstra kompleksitet (og ideelt sett med minst en ekstra Bitcoin-protokolloppgradering som Noinput), kan overføringer til og med fullføres utenfor kjeden. Når Alice betaler Bob, vil alle deltakerne i dette tilfellet opprette en transaksjon som bruker penger til en ny betalingsmasse akkurat det samme, 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 saldoen “internt” og til og med la Dave komme ut i bassenget på et eller annet tidspunkt. Når de alle er enige om å stenge bassenget, kan de opprette en siste transaksjon som brukes fra den opprinnelige betalingsmassen, og tildele hver sin siste saldo.

I likhet med en eldre idé kjent som Channel Factories, kan disse typer betalingsbassenger til slutt til og med brukes til å være vert for lynkanaler, hvelv eller andre Layer Two-protokoller. Dette kan tilby potensialet til å “pakke” alle typer tilleggsprotokolllag i slike bassenger, og dermed skjule all deres kompleksitet i identiske og regelmessige transaksjoner.