Este artigo trata de um conceito tecnológico baseado na proposta de atualização do protocolo Taproot. Se você ainda não está familiarizado com os princípios básicos de como Taproot funciona, é recomendável que você leia primeiro este explicador.
Taproot, uma atualização potencial para o protocolo Bitcoin proposto inicialmente pelo contribuidor do Bitcoin Core Gregory Maxwell, está em seus estágios finais de desenvolvimento. A tecnologia consiste em uma combinação inteligente de truques de criptografia que permitiria aos usuários ocultar contratos inteligentes complexos dentro de transações de aparência normal - a complexidade só é revelada se as partes de um contrato não cooperarem.
Aproveitando essa ideia, os contribuidores do Bitcoin Core, incluindo (mas não se limitando a) Jeremy Rubin, Antoine Riard, Gleb Naumenko e o próprio Gregory Maxwell têm especulado sobre um conceito geral conhecido como pools de pagamento, joinpools ou coinpools. Esses pools - continuaremos a chamá-los de pools de pagamento por enquanto - permitiriam que grupos de usuários compartilhassem a propriedade das mesmas moedas (tecnicamente: UTXOs), conforme registrado no blockchain do Bitcoin, permitindo que qualquer um desses usuários faça (ou receba) pagamentos com eles. Como o grupo e seus membros individuais “se escondem” em uma estrutura Taproot, todos eles desfrutam de mais privacidade, flexibilidade de contrato inteligente e outros benefícios ... e eles potencialmente até desfrutam desses benefícios fora da cadeia, tornando os pools de pagamento uma nova solução de Camada Dois.
Embora as especificações do projeto variem um pouco de uma proposta de pool de pagamento para outra, o conceito geral é o mesmo. Aqui está a ideia básica ...
Compartilhando uma moeda
Primeiro, para criar um pool de pagamento, os usuários combinam suas (frações de) moedas agregando-as em um endereço Taproot compartilhado entre eles. Então, digamos que Alice possui três moedas, Bob possui duas moedas e Carol possui uma moeda, para um total de seis. Juntos, eles criam uma transação que envia essas moedas para o endereço compartilhado, tornando-o um pool de pagamento com seis moedas.
No blockchain, o endereço do pool de pagamento parece um endereço Bitcoin normal, agora com seis moedas. Mas, por baixo da superfície, Alice, Bob e Carol habilmente usaram Taproot para garantir que cada um deles permanecesse no controle de sua própria parcela de moedas no pool de pagamento. Alice pode, a qualquer momento, reivindicar três moedas do endereço, Bob pode, a qualquer momento, reivindicar duas e Carol, uma.
Isso ocorre porque existem apenas duas opções principais para gastar moedas no endereço.
A primeira opção é gastar diretamente do endereço, em termos técnicos, o caminho-chave Taproot. Isso requer cooperação (ou seja: assinaturas criptográficas) de todos os três participantes. Se Alice, Bob e Carol concordarem, as seis moedas podem ser gastas como quiserem, e isso será semelhante a qualquer outra transação regular na rede Bitcoin. O trio pode, por exemplo, decidir enviar seus respectivos saldos de volta para endereços individuais: três para Alice, dois para Bob e um para Carol. Mas, se assim o desejassem, também poderiam cooperar para doar todas as seis moedas a Julian ou gastá-las de qualquer outra forma que concordassem. O importante é que todos os três precisam participar, para que o saldo de ninguém seja gasto sem sua própria cooperação.
A segunda opção principal consiste em várias subopções. Antes de enviar suas moedas para o pool de pagamento, Alice, Bob e Carol esconderam algo na árvore criptográfica atrás do endereço Taproot: eles incluíram formas alternativas de enviar fundos do pool de pagamento. (Atualmente, isso pode ser realizado fazendo com que todos os três participantes assinem previamente as transações a partir desses caminhos, o que exigiria alguma complexidade para configurar todas as opções e não pode ser escalado muito bem; as atualizações de protocolo propostas podem tornar isso mais fácil no futuro .)
Se um dos participantes escolher gastar as moedas no pool de pagamento por meio de um caminho Taproot alternativo, ele normalmente enviará uma quantia correspondente ao saldo desse participante para um endereço de sua escolha, como um endereço individual que ele controla. (No caso de Alice, três moedas para o endereço dela, no caso de Bob duas para o endereço dele e no caso de Carol uma.)
Usando este caminho alternativo, as moedas restantes também são gastas automaticamente. Isso pode ser feito de várias maneiras, dependendo do projeto do pool de pagamento, oferecendo diferentes compensações em relação à complexidade e escalabilidade.
A solução mais simples é enviar a todos os outros participantes também sua cota de moedas, para um endereço de sua escolha. Em outras palavras: se um usuário sai do pool, todos saem do pool.
Uma segunda solução, preferida por Riard e Naumenko, é enviar todas as moedas restantes para um novo pool de pagamento, que se parece exatamente com o primeiro pool de pagamento, apenas retirado de qualquer coisa que envolvesse o usuário que saiu agora. Este design oferece a melhor experiência do usuário, mas é o mais difícil de escalar, principalmente porque é necessário se preparar para todos os cenários de saída possíveis, incluindo todos os cenários de saída possíveis para todos os novos pools em potencial. A escala poderia, no entanto, ser alcançada com uma potencial atualização do protocolo Bitcoin ainda a ser nomeada para garantir que as regras do pool de pagamento anterior sejam transportadas para qualquer novo pool de pagamento.
Rubin acredita que esta segunda solução é impraticável, no entanto, prefere ir para algo entre a primeira e a segunda soluções: alguns participantes recebem imediatamente suas moedas em um endereço de sua escolha, outros participantes têm suas moedas enviadas para um novo pool de pagamento. Esse design oferece uma experiência de usuário menos ideal, mas escalonaria melhor, e a possível atualização do protocolo OP_CHECKTEMPLATEVERIFY ajudaria a simplificar o design e aumentar ainda mais a escala. (As saídas aconteceriam por meio do Tree Payments; esses tipos de pagamentos são explorados mais adiante em Este artigo.)
(Há mais compensações entre a segunda e a terceira soluções, mas os detalhes de todos os prós e contras estão fora do escopo deste artigo; leia o discussão na lista de discussão bitcoin-dev para detalhes.)
Para ver o que significa quando as moedas restantes são enviadas para um novo pool de pagamento, digamos que Alice, Bob e Carol escolham a segunda opção, onde todos os as moedas restantes são enviadas para um novo pool de pagamento. Se, neste design, Alice sair do primeiro pool de pagamento, três moedas serão enviadas para um endereço de sua escolha, enquanto as outras três moedas serão enviadas para um novo pool de pagamento entre Bob e Carol. Nesse ponto, Alice tem controle total sobre suas próprias moedas novamente, embora nada tenha mudado para Bob e Carol. Os dois ainda podem cooperar para gastar as três moedas restantes da maneira que desejarem, ou qualquer um deles pode sair unilateralmente, como Alice havia feito antes.
Se Bob sair unilateralmente do segundo pool de pagamento, ele enviará duas moedas para um endereço de sua escolha e uma moeda para um pool de pagamento ainda mais novo (o terceiro), restando apenas Carol. (Claro, neste exemplo simplificado, um design onde este último pool de pagamento é substituído por um endereço de escolha de Carol na realidade faria mais sentido, mas isso é um detalhe de implementação.)
A lição importante é que os participantes de um pool de pagamento podem cooperar para fazer qualquer tipo de pagamento do pool que desejarem, enquanto qualquer um deles pode, a qualquer momento, sair com suas próprias moedas, deixando os outros participantes no controle das suas.
Colocando o pagamento no pool de pagamentos
Portanto, estabelecemos que todos os participantes podem retirar seu saldo individualmente de um pool de pagamento ou - se todos concordarem - gastar do pool. É esta segunda opção que realmente permite algo inteligente: o pool de pagamento pode ser dinâmico. Contanto que todos os participantes concordem, eles não podem apenas pagar a si mesmos seus fundos ou pagar a outros (como Julian), mas podem fazer algo ainda mais interessante. Eles podem mover seus fundos para versões mais recentes do pool de pagamentos, com designs diferentes.
Isso, por exemplo, permite que qualquer um deles gaste do pool.
Digamos que Alice esteja comprando um carro novo e queira pagar por ele com um bitcoin. Alice, Bob e Carol poderiam então criar uma transação do pool de pagamento que envia uma moeda para a concessionária de automóveis e envia as cinco moedas restantes para um novo pool de pagamento que parece o mesmo que o primeiro, exceto que desta vez Alice só pode sair dele unilateralmente com duas moedas, uma a menos do que antes.
A transação, entretanto, parecia qualquer outra transação normal de Bitcoin. A concessionária de automóveis (ou espiões do blockchain) pode concluir que Alice possuía todas as seis moedas e simplesmente usou uma para comprar o carro, e manteve as outras cinco como troco. Eles não teriam ideia de que algumas das moedas pertencem a Bob e Carol, ou que eles estavam envolvidos na transação.
Da próxima vez, quando Bob fizer um pagamento e Alice e Carol cooperarem, ele será feito do mesmo pool de pagamentos, mais uma vez parecendo uma transação comum de Bitcoin para o mundo exterior. Na iteração resultante do pool de pagamentos, Bob pode sair com uma moeda em vez de duas. Enquanto isso, os mesmos espiões do blockchain podem ter pensado que Alice estava fazendo um pagamento novamente, confundindo-os ainda mais. (E mesmo se os espiões do blockchain descobrissem de alguma forma que o endereço é realmente um pool de pagamento entre Alice, Bob e Carol, eles ainda não poderiam dizer qual dos três fez o último pagamento.)
Cada vez que Alice, Bob ou Carol gastam moedas, a transação pode ter vindo de qualquer um deles, e ninguém fora do pool de pagamento pode dizer a diferença.
Os pools de pagamento não permitem apenas gastos. Se Alice quiser recarregar seu “saldo” no pool de pagamento, ela também poderá fazer isso. Alice, Bob e Carol, neste caso, cooperariam para mover as cinco moedas atuais para um novo endereço Taproot, para o qual Alice, na mesma transação, enviaria uma moeda adicional de um de seus próprios endereços (individuais). O novo endereço da Taproot conteria mais uma vez seis moedas, três das quais pertencentes a Alice, conforme refletido em sua opção de saída unilateral.
Da mesma forma, usuários totalmente novos também podem ingressar no pool de pagamento. Se Alice, Bob e Carol concordarem em deixar Dave participar, os três cooperam com Dave para criar uma transação que envia os fundos do pool de pagamento junto com as novas moedas de Dave para um novo pool de pagamento, projetado para também permitir que Dave participe - e saia se ele assim o escolher.
Além disso, existe a opção de os participantes dentro do pool de pagamento pagarem uns aos outros. Se Alice, por exemplo, pagasse a Bob uma moeda, os três poderiam cooperar para enviar os fundos para um novo pool de pagamento onde Alice tem uma moeda subtraída de seu saldo e Bob tem uma moeda adicionada. No blockchain, novamente, pareceria um pagamento regular, e os espiões do blockchain não teriam ideia de quem pagou quem ou quanto. (É importante ressaltar que Dave poderia ter entrado de forma semelhante no pool, ao receber um pagamento interno de um dos participantes existentes.)
Com um pouco de complexidade extra (e de preferência com pelo menos uma atualização de protocolo Bitcoin extra como Sem entrada), as transferências também podem ser concluídas fora da cadeia. Quando Alice paga Bob, todos os participantes criariam, neste caso, uma transação gastando fundos para um novo pool de pagamento da mesma forma, mas essa transação seria apenas compartilhada entre eles - não transmitida para a rede (a menos que alguém tente trapacear). Dessa forma, Alice, Bob e Carol poderiam continuar atualizando seu saldo “internamente” e até mesmo deixar Dave entrar na piscina em algum momento. Quando todos concordam em fechar o pool, eles podem criar uma transação final que gasta do pool de pagamento original, concedendo a cada um seu último saldo.
Semelhante a uma ideia mais antiga conhecida como Fábricas de canais, esses tipos de pools de pagamento podem, eventualmente, ser usados para hospedar canais Lightning, cofres ou outros protocolos de Camada Dois. Isso pode oferecer o potencial de “envolver” qualquer tipo de camada de protocolo adicional em tais pools, ocultando assim toda a sua complexidade em transações idênticas e de aparência regular.