Dit artikel gaat over een technologisch concept gebaseerd op de voorgestelde upgrade van het Taproot-protocol. Als je nog niet bekend bent met de basisprincipes van hoe Taproot werkt, is het raadzaam dit eerst te lezen deze uitlegger.
hoofdwortel, een mogelijke upgrade van het Bitcoin-protocol dat voor het eerst werd voorgesteld door Bitcoin Core-bijdrager Gregory Maxwell, bevindt zich in de late ontwikkelingsfase. De technologie bestaat uit een slimme combinatie van cryptotrucs waarmee gebruikers complexe slimme contracten kunnen verbergen in normaal ogende transacties – de complexiteit komt alleen aan het licht als partijen bij een contract niet meewerken.
Door gebruik te maken van dit idee hebben Bitcoin Core-bijdragers, waaronder (maar niet beperkt tot) Jeremy Rubin, Antoine Riard, Gleb Naumenko en Gregory Maxwell zelf, gespeculeerd over een algemeen concept dat wordt aangeduid als betalingspools, sluit je aan bij zwembaden of muntenpools. Deze pools – we zullen ze voorlopig betalingspools noemen – zouden groepen gebruikers het eigendom laten delen van dezelfde munten (technisch gezien: UTXO’s) zoals vastgelegd op de Bitcoin-blockchain, terwijl al deze gebruikers betalingen konden doen (of ontvangen). met hen. Terwijl de groep en haar individuele leden zich ‘verstoppen’ in een Taproot-structuur, genieten ze allemaal van meer privacy, slimme contractflexibiliteit en andere voordelen… en mogelijk profiteren ze zelfs buiten de keten van deze voordelen, waardoor betalingspools een nieuwe Layer Two-oplossing worden.
Hoewel de ontwerpspecificaties enigszins variëren van het ene Payment Pool-voorstel tot het andere, is het algemene concept hetzelfde. Hier is het basisidee…
Een munt delen
Om een betalingspool te creëren, combineren gebruikers eerst hun (fracties van) munten door ze samen te voegen in een Taproot-adres dat tussen hen wordt gedeeld. Laten we dus zeggen dat Alice drie munten bezit, Bob twee munten en Carol één munt, voor een totaal van zes. Samen creëren ze een transactie die deze munten naar het gedeelde adres verzendt, waardoor er een betalingspool met zes munten ontstaat.
Op de blockchain lijkt het betalingspooladres op een gewoon Bitcoin-adres, dat nu zes munten bevat. Maar onder de oppervlakte hebben Alice, Bob en Carol op een slimme manier gebruik gemaakt van Taproot om ervoor te zorgen dat ieder van hen de controle behoudt over zijn eigen aandeel aan munten in de betalingspool. Alice kan op elk moment drie munten van het adres claimen, Bob kan er op elk moment twee claimen en Carol één.
Dit komt omdat er slechts twee hoofdopties zijn om munten vanaf het adres uit te geven.
De eerste optie is om rechtstreeks vanaf het adres te besteden, in technische termen het Taproot-sleutelpad. Dit vereist medewerking (dat wil zeggen: cryptografische handtekeningen) van alle drie de deelnemers. Als Alice, Bob en Carol het er allemaal over eens zijn, kunnen de zes munten worden uitgegeven zoals ze willen, en dit zal lijken op elke andere reguliere transactie op het Bitcoin-netwerk. Het trio kan er bijvoorbeeld voor kiezen om hun respectievelijke saldo's terug te sturen naar individuele adressen: drie voor Alice, twee voor Bob en één voor Carol. Maar als ze dat wilden, konden ze ook samenwerken om alle zes de munten aan Julian te doneren, of het geld op een andere manier uit te geven waar ze het over eens waren. Het belangrijkste is dat ze alle drie moeten meedoen, zodat niemands saldo wordt uitgegeven zonder zijn of haar eigen medewerking.
De tweede hoofdoptie bestaat feitelijk uit verschillende subopties. Voordat ze hun munten naar de betalingspool stuurden, verborgen Alice, Bob en Carol iets in de cryptografische boom achter het Taproot-adres: ze bevatten alternatieve manieren om geld uit de betalingspool te sturen. (Momenteel zou dit kunnen worden gerealiseerd door alle drie de deelnemers transacties vanaf deze paden vooraf te laten ondertekenen, wat enige complexiteit zou vergen om alle opties in te stellen en niet erg goed schaalt; voorgestelde protocolupgrades zouden dit in de toekomst mogelijk gemakkelijker kunnen maken .)
Als een van de deelnemers ervoor zou kiezen om de munten in de betalingspool uit te geven via een alternatief Taproot-pad, sturen ze doorgaans een bedrag dat overeenkomt met het saldo van die deelnemer naar een adres van hun keuze, zoals een individueel adres dat zij beheren. (In het geval van Alice drie munten naar haar eigen adres, in het geval van Bob twee naar zijn adres en in het geval van Carol één.)
Via dit alternatieve pad worden de resterende munten automatisch ook uitgegeven. Dit kan op verschillende manieren worden gedaan, afhankelijk van het ontwerp van de betalingspool, waarbij verschillende afwegingen worden gemaakt met betrekking tot complexiteit en schaalbaarheid.
De eenvoudigste oplossing is om alle andere deelnemers hun deel van de munten ook naar een adres naar keuze te sturen. Met andere woorden: als één gebruiker de pool verlaat, verlaat iedereen de pool.
Een tweede oplossing, waaraan Riard en Naumenko de voorkeur geven, is om alle resterende munten naar een nieuwe betalingspool, die er precies zo uitziet als de eerste betalingspool, alleen ontdaan van alles waar de nu verlaten gebruiker bij betrokken was. Dit ontwerp biedt de beste gebruikerservaring, maar is het moeilijkst te schalen, vooral omdat het nodig is om je voor te bereiden op alle mogelijke exitscenario's, inclusief alle mogelijke exitscenario's voor alle potentiële nieuwe pools. Schaal kan echter worden bereikt met een nog te benoemen potentiële Bitcoin-protocolupgrade om ervoor te zorgen dat de regels van de vorige betalingspool worden overgedragen naar elke nieuwe betalingspool.
Rubin vindt deze tweede oplossing echter onpraktisch en gaat liever voor iets tussen de eerste en de tweede oplossing in: sommige deelnemers ontvangen hun munten onmiddellijk op een adres naar keuze, andere deelnemers laten hun munten naar een nieuwe betaalpool sturen. Dit ontwerp biedt een minder ideale gebruikerservaring, maar zou beter kunnen schalen, en de potentiële OP_CHECKTEMPLATEVERIFY-protocolupgrade zou het ontwerp helpen vereenvoudigen en de schaal nog verder vergroten. (Uitgangen zouden gebeuren via Tree Payments; dit soort betalingen worden verder onderzocht in dit artikel.)
(Er zijn meer afwegingen tussen de tweede en derde oplossing, maar de details van alle voor- en nadelen vallen buiten het bestek van dit artikel; lees de bitcoin-dev mailinglijstdiscussie voor details.)
Om te zien wat het betekent als de resterende munten naar een nieuwe betalingspool worden gestuurd, laten we zeggen dat Alice, Bob en Carol de tweede optie kiezen, waarbij allen resterende munten worden naar een nieuwe betalingspool gestuurd. Als Alice in dit ontwerp de eerste betalingspool verlaat, worden drie munten naar een adres naar keuze gestuurd, terwijl de andere drie munten naar een nieuwe betalingspool tussen Bob en Carol worden gestuurd. Alice heeft op dat moment weer de volledige controle over haar eigen munten, terwijl er voor Bob en Carol niet zoveel is veranderd. De twee kunnen nog steeds samenwerken om de drie resterende munten uit te geven zoals ze willen, of een van hen kan eenzijdig vertrekken, zoals Alice eerder had gedaan.
Als Bob vervolgens eenzijdig de tweede betalingspool verlaat, stuurt hij twee munten naar een adres naar keuze, en één munt naar een nog nieuwere betalingspool (de derde), waar alleen Carol nog over is. (In dit vereenvoudigde voorbeeld zou een ontwerp waarbij deze laatste betalingspool wordt vervangen door een adres naar Carol's keuze natuurlijk in werkelijkheid logischer zijn, maar dat is een implementatiedetail.)
Het belangrijkste is dat deelnemers aan een betalingspool kunnen samenwerken om elk type betaling uit de pool te doen die zij willen, terwijl ieder van hen op elk moment kan vertrekken met zijn eigen munten, waardoor andere deelnemers de controle over die van hen overlaten.
De betaling in de betalingspool plaatsen
We hebben dus vastgesteld dat alle deelnemers individueel hun saldo uit een betalingspool kunnen opnemen, of – als ze het er allemaal mee eens zijn – geld uit de pool kunnen uitgeven. Het is deze tweede optie die eigenlijk iets slims mogelijk maakt: de betalingspool kan dynamisch zijn. Zolang alle deelnemers het erover eens zijn, kunnen ze niet alleen zichzelf hun geld terugbetalen, of anderen betalen (zoals Julian), maar kunnen ze iets doen dat nog interessanter is. Ze kunnen hun geld overbrengen naar nieuwere versies van de betalingspool, met verschillende ontwerpen.
Hierdoor kan een van hen bijvoorbeeld geld uit de pool uitgeven.
Laten we zeggen dat Alice een nieuwe auto koopt en deze met één bitcoin wil betalen. Alice, Bob en Carol kunnen dan een transactie uit de betalingspool creëren, waarbij één munt naar de autodealer wordt gestuurd, en de resterende vijf munten naar een nieuwe betalingspool die er hetzelfde uitziet als de eerste, behalve dat Alice er deze keer alleen eenzijdig uit kan komen met twee munten, één minder dan voorheen.
De transactie leek ondertussen op elke andere reguliere Bitcoin-transactie. De autodealer (of blockchain-spionnen) kan concluderen dat Alice alle zes de munten bezat en er eenvoudigweg één gebruikte om de auto te kopen, en de andere vijf als wisselgeld bewaarde. Ze zouden er geen idee van hebben dat sommige munten van Bob en Carol zijn, of dat ze überhaupt bij de transactie betrokken waren.
De volgende keer dat Bob een betaling doet en Alice en Carol samenwerken, wordt deze gedaan vanuit dezelfde betalingspool, waardoor het voor de buitenwereld opnieuw lijkt op een gewone Bitcoin-transactie. In de resulterende versie van de betalingspool kan Bob vertrekken met één munt in plaats van twee. Ondertussen dachten dezelfde blockchain-spionnen misschien dat Alice opnieuw een betaling deed, waardoor ze nog meer in verwarring raakten. (En zelfs als de blockchain-spionnen er op de een of andere manier achter zouden komen dat het adres in werkelijkheid een betalingspool is tussen Alice, Bob en Carol, kunnen ze nog steeds niet zeggen wie van de drie de laatste betaling heeft gedaan.)
Elke keer dat Alice, Bob of Carol munten uitgeven, kan de transactie afkomstig zijn van een van hen, en niemand buiten de betalingspool kan het verschil zien.
Betalingspools maken niet alleen uitgaven mogelijk. Als Alice haar ‘saldo’ in de betalingspool wil aanvullen, kan zij dit ook doen. Alice, Bob en Carol zouden in dit geval samenwerken om de huidige vijf munten naar een nieuw Taproot-adres te verplaatsen, waarnaar Alice in dezelfde transactie één extra munt zou sturen vanaf een van haar eigen (individuele) adressen. Het nieuwe Taproot-adres zou wederom zes munten bevatten, waarvan er drie van Alice zijn, zoals blijkt uit haar eenzijdige exit-optie.
Op dezelfde manier kunnen ook geheel nieuwe gebruikers lid worden van de betalingspool. Als Alice, Bob en Carol ermee instemmen om Dave deel te laten nemen, werken ze alle drie samen met Dave om een transactie tot stand te brengen waarbij het geld van de betalingspool samen met Dave's nieuwe munten naar een nieuwe betalingspool wordt gestuurd, ontworpen om Dave ook te laten deelnemen - en af te sluiten als hij dat zou willen.
Verder is er voor deelnemers binnen de betaalpool de mogelijkheid om elkaar te betalen. Als Alice Bob bijvoorbeeld één munt zou betalen, zouden de drie kunnen samenwerken om het geld naar een nieuwe betalingspool te sturen, waar Alice een munt van haar saldo aftrekt en Bob een munt toevoegt. Op de blockchain zou het er opnieuw uitzien als een gewone betaling, en blockchain-spionnen zouden geen idee hebben wie wie heeft betaald, of hoeveel. (Het is de moeite waard om erop te wijzen dat Dave op een vergelijkbare manier aan de pool had kunnen deelnemen, door een interne betaling te ontvangen van een van de bestaande deelnemers.)
Met een beetje extra complexiteit (en idealiter met minstens één extra Bitcoin-protocolupgrade zoals Geen input), kunnen overdrachten zelfs buiten de keten worden voltooid. Wanneer Alice Bob betaalt, creëren alle deelnemers in dit geval een transactie waarbij geld wordt uitgegeven aan een nieuwe betalingspool, maar deze transactie wordt alleen tussen hen gedeeld en niet naar het netwerk uitgezonden (tenzij iemand ooit probeert vals te spelen). Op deze manier konden Alice, Bob en Carol hun saldo ‘intern’ blijven bijwerken en Dave op een gegeven moment zelfs in het zwembad laten. Wanneer ze er allemaal mee instemmen om de pool te sluiten, kunnen ze een definitieve transactie creëren waarbij de uitgaven uit de oorspronkelijke betalingspool worden besteed, waarbij iedereen zijn/haar laatste saldo krijgt toegekend.
Vergelijkbaar met een ouder idee bekend als Kanaalfabriekenkunnen dit soort betalingspools uiteindelijk zelfs worden gebruikt om Lightning-kanalen, kluizen of andere Layer Two-protocollen te hosten. Dit kan de mogelijkheid bieden om elk type aanvullende protocollaag in dergelijke pools te ‘verpakken’, waardoor al hun complexiteit wordt verborgen in identieke en regelmatig ogende transacties.