Este artículo trata sobre un concepto tecnológico basado en la actualización propuesta del protocolo Taproot. Si aún no está familiarizado con los conceptos básicos de cómo funciona Taproot, se recomienda que primero lea este explicador.
Raíz principal, una posible actualización del protocolo Bitcoin propuesta por primera vez por el colaborador de Bitcoin Core, Gregory Maxwell, se encuentra en sus últimas etapas de desarrollo. La tecnología consiste en una combinación inteligente de trucos criptográficos que permitirían a los usuarios ocultar contratos inteligentes complejos dentro de transacciones de apariencia regular; la complejidad solo se revela si las partes de un contrato no cooperan.
Aprovechando esta idea, los contribuyentes de Bitcoin Core, incluidos (entre otros) Jeremy Rubin, Antoine Riard, Gleb Naumenko y el propio Gregory Maxwell han estado especulando sobre un concepto general al que se hace referencia como grupos de pago, unirse a piscinas o coinpools. Estos grupos, nos limitaremos a llamarlos grupos de pago por ahora, permitirían a grupos de usuarios compartir la propiedad de las mismas monedas (técnicamente: UTXO) registradas en la cadena de bloques de Bitcoin, al tiempo que permiten que cualquiera de estos usuarios realice (o reciba) pagos. con ellos. A medida que el grupo y sus miembros individuales se “esconden” en una estructura Taproot, todos disfrutan de más privacidad, flexibilidad de contratos inteligentes y otros beneficios ... y potencialmente incluso disfrutan de estos beneficios fuera de la cadena, lo que hace que los fondos de pago sean una nueva solución de Capa Dos.
Aunque los detalles de diseño varían un poco de una propuesta de Fondo de Pago a otra, el concepto general es el mismo. Aquí está la idea básica ...
Compartiendo una moneda
Primero, para crear un grupo de pagos, los usuarios combinan sus (fracciones de) monedas agregándolas en una dirección Taproot compartida entre ellos. Entonces, digamos que Alice posee tres monedas, Bob posee dos monedas y Carol posee una moneda, para un total de seis. Juntos, crean una transacción que envía estas monedas a la dirección compartida, convirtiéndola en un grupo de pago con seis monedas.
En la cadena de bloques, la dirección del grupo de pagos parece una dirección Bitcoin normal, que ahora contiene seis monedas. Pero debajo de la superficie, Alice, Bob y Carol usaron inteligentemente Taproot para asegurarse de que cada uno de ellos mantenga el control de su propia porción de monedas en el grupo de pagos. Alice puede reclamar en cualquier momento tres monedas de la dirección, Bob puede reclamar dos en cualquier momento y Carol una.
Esto se debe a que solo hay dos opciones principales para gastar monedas desde la dirección.
La primera opción es gastar directamente desde la dirección, en términos técnicos la ruta de la clave Taproot. Esto requiere la cooperación (es decir, firmas criptográficas) de los tres participantes. Si Alice, Bob y Carol están de acuerdo, las seis monedas se pueden gastar como quieran, y esto se verá como cualquier otra transacción regular en la red Bitcoin. El trío puede, por ejemplo, decidir enviar sus respectivos saldos a direcciones individuales: tres para Alice, dos para Bob y una para Carol. Pero si así lo decidieran, también podrían cooperar para donar las seis monedas a Julian, o gastarlas de cualquier otra forma que pudieran acordar. Lo importante es que los tres deben participar, por lo que nadie se gasta el saldo sin su propia cooperación.
La segunda opción principal en realidad consta de varias subopciones. Antes de enviar sus monedas al grupo de pagos, Alice, Bob y Carol escondieron algo en el árbol criptográfico detrás de la dirección de Taproot: incluyeron formas alternativas de enviar fondos desde el grupo de pagos. (Actualmente, esto se podría lograr haciendo que los tres participantes firmen previamente las transacciones de estas rutas, lo que requeriría cierta complejidad para configurar todas las opciones y no se escala muy bien; las actualizaciones de protocolo propuestas podrían potencialmente facilitar esto en el futuro .)
Si uno de los participantes optara por gastar las monedas en el grupo de pago a través de una ruta alternativa de Taproot, normalmente enviaría una cantidad correspondiente al saldo de ese participante a una dirección de su elección, como una dirección individual que controlan. (En el caso de Alice, tres monedas para su propia dirección, en el caso de Bob, dos para su dirección y en el caso de Carol, una).
Usando esta ruta alternativa, las monedas restantes también se gastan automáticamente. Esto se puede hacer de varias formas dependiendo del diseño del grupo de pagos, ofreciendo diferentes compensaciones en cuanto a complejidad y escalabilidad.
La solución más simple es enviar a todos los demás participantes su parte de monedas también, a la dirección de su elección. En otras palabras: si un usuario sale del grupo, todos salen del grupo.
Una segunda solución, preferida por Riard y Naumenko, es enviar todas las monedas restantes a un nueva grupo de pagos, que se ve exactamente como el primer grupo de pagos, simplemente despojado de todo lo que involucraba al usuario ahora salido. Este diseño ofrece la mejor experiencia de usuario, pero es el más difícil de escalar, sobre todo porque es necesario prepararse para todos los posibles escenarios de salida, incluidos todos los posibles escenarios de salida para todos los posibles grupos nuevos. Sin embargo, la escala se podría lograr con una posible actualización del protocolo de Bitcoin aún por nombrar para garantizar que las reglas del grupo de pagos anterior se transfieran a cualquier nuevo grupo de pagos.
Sin embargo, Rubin cree que esta segunda solución no es práctica y prefiere elegir algo entre la primera y la segunda solución: algunos participantes reciben inmediatamente sus monedas en una dirección de su elección, a otros participantes se les envían sus monedas a un nuevo grupo de pagos. Este diseño ofrece una experiencia de usuario menos ideal, pero se escalaría mejor, y la posible actualización del protocolo OP_CHECKTEMPLATEVERIFY ayudaría a simplificar el diseño y aumentar la escala aún más. (Las salidas ocurrirían a través de Tree Payments; estos tipos de pagos se exploran más en este artículo.)
(Hay más compensaciones entre la segunda y la tercera solución, pero los detalles de todos los pros y los contras están fuera del alcance de este artículo; lea el discusión de la lista de correo de bitcoin-dev para más detalles.)
Para ver qué significa cuando las monedas restantes se envían a un nuevo grupo de pago, digamos que Alice, Bob y Carol eligen la segunda opción, donde todos las monedas restantes se envían a un nuevo grupo de pagos. Si en este diseño, Alice sale del primer grupo de pagos, se envían tres monedas a la dirección que elija, mientras que las otras tres monedas se envían a un nuevo grupo de pagos entre Bob y Carol. Alice en ese momento tiene el control exclusivo sobre sus propias monedas nuevamente, aunque no mucho ha cambiado para Bob y Carol. Los dos aún pueden cooperar para gastar las tres monedas restantes como lo deseen, o cualquiera de ellos puede salir unilateralmente, como había hecho Alice antes.
Si Bob sale unilateralmente del segundo grupo de pagos, envía dos monedas a la dirección de su elección y una moneda a un grupo de pagos aún más nuevo (el tercero) y solo queda Carol. (Por supuesto, en este ejemplo simplificado, un diseño en el que este último grupo de pagos se reemplaza con una dirección de elección de Carol tendría más sentido en realidad, pero ese es un detalle de implementación).
La conclusión importante es que los participantes en un grupo de pagos pueden cooperar para realizar cualquier tipo de pago del grupo que deseen, mientras que cualquiera de ellos puede en cualquier momento salir con sus propias monedas, dejando a otros participantes en control de las suyas.
Poner el pago en el fondo de pago
Por eso, hemos establecido que todos los participantes pueden retirar individualmente su saldo de un grupo de pagos o, si todos están de acuerdo, gastar del grupo. Es esta segunda opción la que realmente permite algo inteligente: el fondo de pagos puede ser dinámico. Siempre que todos los participantes estén de acuerdo, no pueden simplemente reembolsarse sus fondos o pagar a otros (como Julian), sino que pueden hacer algo aún más interesante. Pueden mover sus fondos a versiones más nuevas del grupo de pagos, con diferentes diseños.
Esto, por ejemplo, permite que cualquiera de ellos gaste de la piscina.
Digamos que Alice está comprando un auto nuevo y quiere pagarlo con un bitcoin. Alice, Bob y Carol podrían entonces crear una transacción del grupo de pagos que envía una moneda al concesionario de automóviles y envía las cinco monedas restantes a un nueva grupo de pago que se ve igual que el primero, excepto que esta vez Alice solo puede salir unilateralmente con dos monedas, una menos que antes.
Mientras tanto, la transacción se parecía a cualquier otra transacción regular de Bitcoin. El concesionario de automóviles (o los espías de blockchain) pueden concluir que Alice poseía las seis monedas y simplemente usó una para comprar el automóvil y se quedó con las otras cinco como cambio. No tendrían idea de que algunas de las monedas pertenecen a Bob y Carol, o que estuvieron involucrados en la transacción.
La próxima vez, cuando Bob haga un pago y Alice y Carol cooperen, se hará desde el mismo grupo de pagos, y una vez más se verá como una transacción ordinaria de Bitcoin para el mundo exterior. En la iteración resultante del grupo de pagos, Bob puede salir con una moneda en lugar de dos. Mientras tanto, los mismos espías de blockchain pueden haber pensado que Alice estaba haciendo un pago nuevamente, confundiéndolos aún más. (E incluso si los espías de blockchain de alguna manera se dieran cuenta de que la dirección es realmente un grupo de pagos entre Alice, Bob y Carol, todavía no podrían decir cuál de los tres hizo el último pago).
Cada vez que Alice, Bob o Carol gastan monedas, la transacción puede provenir de cualquiera de ellos, y nadie fuera del grupo de pagos puede notar la diferencia.
Los fondos de pago no solo permiten gastos. Si Alice quiere recargar su "saldo" en el grupo de pagos, también podría hacerlo. Alice, Bob y Carol cooperarían en este caso para mover las cinco monedas actuales a una nueva dirección de Taproot, a la que Alice enviaría en la misma transacción una moneda adicional desde una de sus propias direcciones (individuales). La nueva dirección de Taproot volvería a contener seis monedas, tres de las cuales pertenecen a Alice, como se refleja en su opción de salida unilateral.
De la misma manera, los usuarios completamente nuevos también podrían unirse al grupo de pagos. Si Alice, Bob y Carol aceptan que Dave participe, los tres cooperarán con Dave para crear una transacción que envíe los fondos del grupo de pagos junto con las nuevas monedas de Dave a un nuevo grupo de pagos, diseñado para permitir que Dave también participe y salga. si así lo quisiera.
Además, existe la opción de que los participantes dentro del grupo de pago se paguen entre sí. Si Alice, por ejemplo, le pagara a Bob una moneda, los tres podrían cooperar para enviar los fondos a un nuevo grupo de pagos donde Alice tiene una moneda restada de su saldo y Bob tiene una moneda agregada. En la cadena de bloques, nuevamente, se vería como un pago regular, y los espías de la cadena de bloques no tendrían idea de quién pagó a quién o cuánto. (Vale la pena señalar que Dave podría haber ingresado de manera similar al grupo, al recibir un pago interno de uno de los participantes existentes).
Con un poco de complejidad adicional (e idealmente con al menos una actualización adicional del protocolo Bitcoin como Sin entrada), las transferencias también podrían completarse fuera de la cadena. Cuando Alice le paga a Bob, todos los participantes en este caso crearían una transacción gastando fondos en un nuevo grupo de pagos de la misma manera, pero esta transacción solo se compartiría entre ellos, no se transmitiría a la red (a menos que alguien intente hacer trampa). De esta manera, Alice, Bob y Carol podrían seguir actualizando su balance "internamente" e incluso dejar que Dave ingresara a la piscina en algún momento. Cuando todos acuerdan cerrar el grupo, pueden crear una transacción final que gaste del grupo de pago original, otorgando a cada uno su último saldo.
Similar a una idea anterior conocida como Canal Fábricas, estos tipos de fondos de pago podrían eventualmente usarse para albergar canales Lightning, bóvedas u otros protocolos de Capa Dos. Esto puede ofrecer la posibilidad de "envolver" cualquier tipo de capa de protocolo adicional en dichos grupos, ocultando así toda su complejidad en transacciones idénticas y de apariencia regular.