Ya estamos empezando a ver las semillas del potencial de la segunda capa desarrollarse a partir de los primitivos de la capa base que se han añadido u optimizado en la primera década. Lightning, aunque todavía está sujeto a algunas limitaciones bastante grandes, realmente está empezando a prosperar. Y eso es solo la primera versión limitada que está actualmente especificada e implementada. Ahora hay sidechains de varios tipos desplegados: Liquid, RSK e incluso cadenas de tokens atados a Bitcoin desarrolladas por Commerceblock. Esto es solo el comienzo.
Schnorr and Taproot
Justo más allá del horizonte, tenemos la combinación de Schnorr y Taproot. En el lado de Schnorr, este es un esquema de firma mucho más barato de verificar en lotes, así como el próximo gran salto en la optimización de la construcción de scripts multi-firma en Bitcoin. Multisig comenzó como simplemente incorporar todas las claves públicas y el script para el multisig en una salida de transacción para enviarla, y tener que incluir todo eso en la entrada para gastarla. P2SH optimizó el aspecto de salida, al incluir una longitud constante de hash de las claves públicas y scripts del multisig, ahorrando tarifas a cualquiera que envíe a una dirección multisig y dejando un costo aumentado solo para el remitente. SegWit argumentablemente "optimizó" aún más al hacer que el gasto de UTXOs multisig sea más barato con el descuento del testigo. Schnorr lleva toda esta optimización incremental al extremo. Combina las claves públicas individuales en una sola clave, en la que todos pueden colaborar para hacer una firma única, y simplemente comprobar eso. Esto crea ahorros masivos de costos para todo el uso de multisig, incluyendo capas secundarias como Lightning y sidechains federados, y también crea un beneficio de privacidad al hacer que todos estos UTXOs multisig sean indistinguibles de los de una sola firma.
Ahora, eso no hace que todo sea completamente privado de forma mágica. Los estados de los canales de Lightning (transactions) todavía requieren rutas de clave separadas para sus transacciones de penalización para reaccionar a la presentación de estados antiguos. Eso significa que tienen que estar en los scripts de salida, lo que crea una huella digital. Taproot resuelve esto con su cripto-magia que te permite comprometer un árbol de merkle de diferentes condiciones de gasto, que solo requieren la condición utilizada y la prueba de merkle hasta la raíz de merkle para gastar, a una clave pública Schnorr de aspecto normal. Ahora puedes ocultar esa ruta de script de penalización con taproot. Puedes ocultar cualquier ruta de script condicional con Taproot, enterrada bajo una clave Schnorr de aspecto perfectamente normal que permite a todos los participantes ponerse de acuerdo en algo y hacer una transacción de aspecto perfectamente normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (anteriormente SIGHASH_NOINPUT) es esperanzadamente la próxima nueva primitiva que se espera en un futuro cercano. Se trata de un nuevo formato de clave pública/actualización de bandera sighash. Las banderas sighash especifican a qué partes de una transacción se compromete una firma. Esta funcionalidad existe para que puedas hacer algo como firmar solo tu entrada y salidas, pero permitir que otras personas añadan sus propias entradas y salidas a una transacción sin invalidarla. Pero actualmente, una firma tiene que comprometerse con un UTXO exacto de una transacción exacta. SIGHASH_ANYPREVOUT, entre otras cosas, permitiría comprometer una firma solo con un script de UTXO, no con un UTXO específico real. Esto permite una nueva forma (eltoo) de construir estados de canal Lightning que no requiere una clave de penalización o lidiar con estados antiguos al permitir a la parte engañada confiscar todo el dinero. En lugar de eso, el estado actual del canal simplemente podría volver a gastar el antiguo estado del canal si perdiera la carrera de doble gasto, garantizando que todos reciban su saldo actual del canal en la cadena en lugar de un saldo desactualizado anterior. Se logra esto simplemente reutilizando el mismo script en el lugar correcto y utilizando SIGHASH_ANYPREVOUT.
Esto elimina muchos riesgos con respecto a perder estados de canal actuales que resulten en una transacción de penalización que tome sus fondos por un error honesto. También permite MUCHO más. Ahora podemos tener canales Lightning con más de 2 participantes e incluso podemos apilar "subcanales" encima de esos. Además, SIGHASH_ANYPREVOUT y eltoo permiten la creación de Statechains, un tipo de construcción de canal federado que permite que los nuevos participantes entren y salgan completamente fuera de la cadena con la suposición de confianza de que la federación no conspirará con participantes pasados para defraudar a nadie. Esto abre mucho potencial para lo que he estado llamando a mí mismo "protocolos de UTXO estáticos multiparte".
OP_CHECKTEMPLATEVERIFY
OP_CTV es una propuesta de Jeremy Rubin para habilitar un tipo muy básico de "pacto" en Bitcoin. Un pacto es más complicado que las restricciones para gastar una moneda más allá de las firmas de ciertas llaves. El tipo de pacto que implementaría la propuesta de Rubin es una "plantilla". Esencialmente, esto permite que el script de un UTXO requiera que la transacción de gasto cree salidas exactas específicas. Por lo tanto, una vez que se crea un UTXO utilizando OP_CTV, se aplica por consenso que el UTXO debe gastarse en direcciones específicas en las cantidades específicas definidas en el script de ese UTXO. Incluso puede encadenarlos para que uno de estos UTXO se vea obligado a hacer algunos más, que luego se ven obligados a hacer algunos más, y así sucesivamente.
Esto tiene una enorme aplicabilidad general en todas partes. En entornos de tarifas altas, una sola UTXO puede ser creada por una entidad de custodia que 100% bajo reglas de consenso garantiza que todos los fondos de sus clientes terminarán bajo el control de sus clientes, aunque no tengan acceso inmediato a ellos en el momento. Esto tiene una gran sinergia potencial con los canales multipartidistas (channel factories), en el sentido de que una "retirada" masiva realizada de esta manera también puede crear y usarse simultáneamente como una fábrica de canales. OP_CTV se puede utilizar para crear canales de pago que al menos funcionen unidireccionalmente sin que el extremo receptor tenga que participar o tener una clave en línea para recibir pagos (and recuerde que puede apilar canales encima de cada other). Incluso se puede usar para permitir que un solo canal procese más HTLC a la vez agrupándolos con el mismo truco que usa el primer ejemplo con retiros de custodia. E incluso podría crear cierto potencial para nuevos tipos de coinjoins.
Poniendo Todo Junto
Suponiendo que todas las propuestas anteriores sean adoptadas e incorporadas en Bitcoin, realmente creo que, aparte de los desarrolladores que trabajan en la vanguardia de estas cosas, la gente ni siquiera tiene la más mínima idea de qué tipos de protocolos y servicios se construirán utilizando estos elementos primitivos. O las cosas extrañas donde no hay una clara línea divisoria entre servicio o protocolo.
Habilitarán canales multipartitos con números de participantes teóricamente ilimitados, que pueden apilar subcanales en la parte superior con subgrupos más pequeños de los participantes del canal base. Los canales se pueden construir sobre estas "fábricas de canales" que permiten a las personas recibir dinero sin tener claves en línea para una billetera caliente. Estos canales multipartitos se pueden apilar sobre canales federados (statechains) que permiten a los participantes entrar o salir con cero actividad en cadena. Y la construcción del "empalme" de canales permitirá que la liquidez se mueva de manera relativamente fluida entre diferentes canales de manera que permitirá todo tipo de cosas en las que la gente ni siquiera ha comenzado a pensar.
Mi última palabra en esta sección es: esto solo considera lo que se puede hacer con las cosas que considero partes directas del conjunto de protocolos de Bitcoin en sí mismo. Se puede hacer mucho más si empiezas a mirar los servicios de custodia centralizados, y qué subconjunto de las propiedades de Bitcoin pueden proporcionar, ignorando las barreras regulatorias o legales para hacerlo.
Esta es solo la Parte 2 de 4, lee la siguiente parte mañana
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
La próxima década, parte 2: El camino por delante
Ya estamos empezando a ver las semillas del potencial de la segunda capa desarrollarse a partir de los primitivos de la capa base que se han añadido u optimizado en la primera década. Lightning, aunque todavía está sujeto a algunas limitaciones bastante grandes, realmente está empezando a prosperar. Y eso es solo la primera versión limitada que está actualmente especificada e implementada. Ahora hay sidechains de varios tipos desplegados: Liquid, RSK e incluso cadenas de tokens atados a Bitcoin desarrolladas por Commerceblock. Esto es solo el comienzo.
Schnorr and Taproot
Justo más allá del horizonte, tenemos la combinación de Schnorr y Taproot. En el lado de Schnorr, este es un esquema de firma mucho más barato de verificar en lotes, así como el próximo gran salto en la optimización de la construcción de scripts multi-firma en Bitcoin. Multisig comenzó como simplemente incorporar todas las claves públicas y el script para el multisig en una salida de transacción para enviarla, y tener que incluir todo eso en la entrada para gastarla. P2SH optimizó el aspecto de salida, al incluir una longitud constante de hash de las claves públicas y scripts del multisig, ahorrando tarifas a cualquiera que envíe a una dirección multisig y dejando un costo aumentado solo para el remitente. SegWit argumentablemente "optimizó" aún más al hacer que el gasto de UTXOs multisig sea más barato con el descuento del testigo. Schnorr lleva toda esta optimización incremental al extremo. Combina las claves públicas individuales en una sola clave, en la que todos pueden colaborar para hacer una firma única, y simplemente comprobar eso. Esto crea ahorros masivos de costos para todo el uso de multisig, incluyendo capas secundarias como Lightning y sidechains federados, y también crea un beneficio de privacidad al hacer que todos estos UTXOs multisig sean indistinguibles de los de una sola firma.
Ahora, eso no hace que todo sea completamente privado de forma mágica. Los estados de los canales de Lightning (transactions) todavía requieren rutas de clave separadas para sus transacciones de penalización para reaccionar a la presentación de estados antiguos. Eso significa que tienen que estar en los scripts de salida, lo que crea una huella digital. Taproot resuelve esto con su cripto-magia que te permite comprometer un árbol de merkle de diferentes condiciones de gasto, que solo requieren la condición utilizada y la prueba de merkle hasta la raíz de merkle para gastar, a una clave pública Schnorr de aspecto normal. Ahora puedes ocultar esa ruta de script de penalización con taproot. Puedes ocultar cualquier ruta de script condicional con Taproot, enterrada bajo una clave Schnorr de aspecto perfectamente normal que permite a todos los participantes ponerse de acuerdo en algo y hacer una transacción de aspecto perfectamente normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (anteriormente SIGHASH_NOINPUT) es esperanzadamente la próxima nueva primitiva que se espera en un futuro cercano. Se trata de un nuevo formato de clave pública/actualización de bandera sighash. Las banderas sighash especifican a qué partes de una transacción se compromete una firma. Esta funcionalidad existe para que puedas hacer algo como firmar solo tu entrada y salidas, pero permitir que otras personas añadan sus propias entradas y salidas a una transacción sin invalidarla. Pero actualmente, una firma tiene que comprometerse con un UTXO exacto de una transacción exacta. SIGHASH_ANYPREVOUT, entre otras cosas, permitiría comprometer una firma solo con un script de UTXO, no con un UTXO específico real. Esto permite una nueva forma (eltoo) de construir estados de canal Lightning que no requiere una clave de penalización o lidiar con estados antiguos al permitir a la parte engañada confiscar todo el dinero. En lugar de eso, el estado actual del canal simplemente podría volver a gastar el antiguo estado del canal si perdiera la carrera de doble gasto, garantizando que todos reciban su saldo actual del canal en la cadena en lugar de un saldo desactualizado anterior. Se logra esto simplemente reutilizando el mismo script en el lugar correcto y utilizando SIGHASH_ANYPREVOUT.
Esto elimina muchos riesgos con respecto a perder estados de canal actuales que resulten en una transacción de penalización que tome sus fondos por un error honesto. También permite MUCHO más. Ahora podemos tener canales Lightning con más de 2 participantes e incluso podemos apilar "subcanales" encima de esos. Además, SIGHASH_ANYPREVOUT y eltoo permiten la creación de Statechains, un tipo de construcción de canal federado que permite que los nuevos participantes entren y salgan completamente fuera de la cadena con la suposición de confianza de que la federación no conspirará con participantes pasados para defraudar a nadie. Esto abre mucho potencial para lo que he estado llamando a mí mismo "protocolos de UTXO estáticos multiparte".
OP_CHECKTEMPLATEVERIFY
OP_CTV es una propuesta de Jeremy Rubin para habilitar un tipo muy básico de "pacto" en Bitcoin. Un pacto es más complicado que las restricciones para gastar una moneda más allá de las firmas de ciertas llaves. El tipo de pacto que implementaría la propuesta de Rubin es una "plantilla". Esencialmente, esto permite que el script de un UTXO requiera que la transacción de gasto cree salidas exactas específicas. Por lo tanto, una vez que se crea un UTXO utilizando OP_CTV, se aplica por consenso que el UTXO debe gastarse en direcciones específicas en las cantidades específicas definidas en el script de ese UTXO. Incluso puede encadenarlos para que uno de estos UTXO se vea obligado a hacer algunos más, que luego se ven obligados a hacer algunos más, y así sucesivamente.
Esto tiene una enorme aplicabilidad general en todas partes. En entornos de tarifas altas, una sola UTXO puede ser creada por una entidad de custodia que 100% bajo reglas de consenso garantiza que todos los fondos de sus clientes terminarán bajo el control de sus clientes, aunque no tengan acceso inmediato a ellos en el momento. Esto tiene una gran sinergia potencial con los canales multipartidistas (channel factories), en el sentido de que una "retirada" masiva realizada de esta manera también puede crear y usarse simultáneamente como una fábrica de canales. OP_CTV se puede utilizar para crear canales de pago que al menos funcionen unidireccionalmente sin que el extremo receptor tenga que participar o tener una clave en línea para recibir pagos (and recuerde que puede apilar canales encima de cada other). Incluso se puede usar para permitir que un solo canal procese más HTLC a la vez agrupándolos con el mismo truco que usa el primer ejemplo con retiros de custodia. E incluso podría crear cierto potencial para nuevos tipos de coinjoins.
Poniendo Todo Junto
Suponiendo que todas las propuestas anteriores sean adoptadas e incorporadas en Bitcoin, realmente creo que, aparte de los desarrolladores que trabajan en la vanguardia de estas cosas, la gente ni siquiera tiene la más mínima idea de qué tipos de protocolos y servicios se construirán utilizando estos elementos primitivos. O las cosas extrañas donde no hay una clara línea divisoria entre servicio o protocolo.
Habilitarán canales multipartitos con números de participantes teóricamente ilimitados, que pueden apilar subcanales en la parte superior con subgrupos más pequeños de los participantes del canal base. Los canales se pueden construir sobre estas "fábricas de canales" que permiten a las personas recibir dinero sin tener claves en línea para una billetera caliente. Estos canales multipartitos se pueden apilar sobre canales federados (statechains) que permiten a los participantes entrar o salir con cero actividad en cadena. Y la construcción del "empalme" de canales permitirá que la liquidez se mueva de manera relativamente fluida entre diferentes canales de manera que permitirá todo tipo de cosas en las que la gente ni siquiera ha comenzado a pensar.
Mi última palabra en esta sección es: esto solo considera lo que se puede hacer con las cosas que considero partes directas del conjunto de protocolos de Bitcoin en sí mismo. Se puede hacer mucho más si empiezas a mirar los servicios de custodia centralizados, y qué subconjunto de las propiedades de Bitcoin pueden proporcionar, ignorando las barreras regulatorias o legales para hacerlo.
Esta es solo la Parte 2 de 4, lee la siguiente parte mañana