Las billeteras en cadena logran un mapeo aproximado de 1 a 1 de transacciones a transacciones: para cada transacción económica que realiza un usuario, aproximadamente se necesita una transacción en la cadena de bloques. Las agregaciones, coinjoin, pagos de corte, etc. cambian un poco esta afirmación. Pero es aproximadamente correcta.

Lightning logró un mapeo de muchos a uno de transacciones a transacciones: la magia de Lightning es que un número efectivamente infinito de transacciones económicas puede ocurrir en un solo canal Lightning, que a su vez está ligado a una única salida de transacción no gastada (UTXO). Básicamente, hemos tomado la dimensión de "tiempo" - transacciones - y logrado un escalado significativo al colapsar esa dimensión.

Pero podría decirse que crear incluso un solo UTXO por usuario no es suficiente. Por lo tanto, existen muchas propuestas para lograr un escalado aún mayor al permitir que varios usuarios compartan un solo UTXO de forma autosoberana. De nuevo, colapsando otra dimensión "espacial" de escalado (usuarios) en una UTXO.

Nuestro objetivo aquí es hacer una visión general de todas estas propuestas, averiguar qué patrones técnicos comparten, descubrir qué tipos de nuevos códigos de operación y otras actualizaciones de bifurcación suave necesitan para funcionar y crear una tabla de comparación de cómo todas las partes encajan juntas. En el camino, también definiremos qué es realmente un protocolo L2, qué tipo de escalabilidad ya es capaz Lightning y entenderemos qué mejoras necesitamos hacer en los mempools para lograr todo esto.

Gracias va aFulgur Venturespor patrocinar esta investigación. No tuvieron control editorial sobre el contenido de esta publicación y no lo revisaron antes de su publicación.

También gracias a Daniela Brozzoni, Sarah Cox, y otros para revisión previa a la publicación.

Definiciones

¿Qué es Capa 2?

A menudo, el término "Capa 2" se define de manera amplia, hasta el punto en que incluso una entidad similar a un banco (por ejemplo, Liquid) podría ser definida como una Capa 2. Para los fines de este artículo, adoptaremos una definición estricta: una Capa 2 (L2) es un sistema denominado en Bitcoin, con el propósito de permitir que se realicen transacciones con BTC con más frecuencia que el número de transacciones en cadena con otras partes. De tal manera que cualquiera de las siguientes opciones:

1. Nadie puede robar fondos de forma rentable en el sistema, teniendo en cuenta los castigos y costos dentro del sistema. Los costos y castigos fuera del sistema, como la pérdida de reputación, las consecuencias legales, etc., no se consideran en nuestra definición.
2. (Preferido) Los verdaderos propietarios de los fondos pueden retirar unilateralmente sus fondos, menos las tarifas de transacción, sin la cooperación de terceros.

La primera opción es necesaria porque queremos que nuestros sistemas L2 sean capaces de representar cantidades y transacciones de un valor tan pequeño que no puedan representarse en la cadena. Por ejemplo, en Lightning, los HTLC pueden tener un valor demasiado pequeño para representarlos en la cadena. En esa circunstancia, el valor de HTLC se agrega a la tarifa de transacción de la transacción de compromiso. Si bien un nodo Lightning puede "robar" un HTLC de polvo cerrando un canal en el momento adecuado, hacerlo es más costoso¹que el valor de HTLC, lo que hace que el robo no sea rentable.

Dicho esto, la retirada unilateral es siempre nuestro objetivo de diseño principal.²

Con esta definición, cosas como Lightning se consideran sistemas de Capa 2. Sin embargo, sistemas como Liquid, Cashu y Fedimint no son Capas 2, porque otra parte o partes tienen el control de tus fondos. Los esquemas de validación del lado del cliente como RGB tampoco son Capas 2 según esta definición, porque no pueden realizar transacciones de BTC de manera confiable. Finalmente,@RubenSomsenStatechains no logra hacer el corte, porque la entidad de Statechain puede robar fondos si no siguen el protocolo.

¿Qué son los Pactos?

... y ¿por qué los sistemas L2 más escalables los necesitan?

En la programación de Bitcoin, los convenios son mecanismos mediante los cuales se restringe de antemano la forma en que se puede gastar un txout, de tal manera que la forma en que se utilizan las transacciones para gastar ese txout está predefinida o de alguna otra manera restringida de una manera que no se limita solo a las firmas. Los sistemas L2 que comparten UTXO entre múltiples partes necesitan convenios porque necesitan formas de restringir cómo se puede gastar el UTXO para implementar las reglas e incentivos del protocolo L2.

Convenios Recursivos

Un convenio recursivo es un convenio con la propiedad de que las reglas que limitan cómo se puede gastar un UTXO pueden aplicarse de forma recursiva a los UTXO hijos de la transacción de gasto indefinidamente. Los convenios recursivos tienen durante mucho tiempo se ha considerado indeseable por algunosporque pueden gravar monedas indefinidamente. O al menos, indefinidamente sin el permiso de un tercero como un gobierno.

Metas

Lightning es el sistema Layer 2 actualmente considerado como el "mejor de su clase". Sin embargo, tiene limitaciones. Específicamente:

1. Escalabilidad: Lightning actualmente requiere al menos un UTXO por usuario final.³
2. La liquidez: Lightning requiere que los fondos estén atados en canales.
3. La interactividad: Lightning requiere que los destinatarios de los pagos estén en línea para recibirlos de manera confiable.

Al evaluar los sistemas de Capa 2, nuestro objetivo será mejorar estas limitaciones clave, idealmente sin agregar nuevas limitaciones.

Límites de escalado de Lightning

¿Qué significa en la práctica “un UTXO por usuario final”? Dado que los canales Lightning pueden operar indefinidamente, una forma de ver esto es preguntarse cuántos canales nuevos se pueden crear por año⁴. Crear una salida de raíz de grifo tiene un costo marginal de 43vB; si la creación de canales se amortiza, con muchos canales creados en una sola transacción, el otro gasto de transacción se puede hacer insignificante y se pueden abrir cantidades bastante grandes de canales por año para incorporar nuevos usuarios. Por ejemplo, supongamos que el 90% de la capacidad del bloque se destinó a abrir nuevos canales Lightning de raíz de grifo:

Se estima que alrededor de la mitad de la población mundial posee un teléfono inteligente, 4.3 billion people. Por lo tanto, de hecho, podemos incorporar un porcentaje significativo de toda la población que probablemente pueda hacer uso de un canal Lightning por año.

Sin embargo, los canales no duran para siempre. En ocasiones, los usuarios querrán cambiar de billetera, aumentar o disminuir la capacidad del canal, etc. El método más eficiente para cambiar la capacidad de un canal es a través de empalme, notablemente implementado en Phoenix Wallet.

Al igual que la apertura de canales, el empalme también se puede realizar de manera amortizada para mejorar la eficiencia, con múltiples operaciones de empalme compartiendo una sola transacción para reducir el número de entradas y salidas necesarias para agregar y retirar fondos⁵. Por lo tanto, el espacio de bloque delta requerido por empalme de los usuarios, asumiendo el uso de musig, es la salida de taproot 43vB más la

57.5vB gasto de ruta clave de taproot, para un total de 100.5vB. Si asumimos nuevamente un uso del espacio de bloque del 90%, obtenemos:

Finalmente, note cómo cambiar los canales Lightning entre billeteras puede hacerse en una sola transacción, ya sea confiando en que la próxima billetera firme una transacción de compromiso después de que los fondos se hayan enviado a la dirección de compromiso, o con el soporte de cierre cooperativo de nuevo canal en ambas implementaciones de billetera.

Por supuesto, hay casos de uso competidores para Bitcoin más allá de los canales Lightning, y cómo se traducirá esto en las tasas de comisión es difícil de saber. Pero estos números nos dan una idea aproximada que sugiere que con la tecnología actual, al menos es técnicamente posible admitir cientos de millones de usuarios de Lightning auto-soberanos.

Visión general de Capa 2

Bajo nuestra definición de sistemas de Capa 2, hay dos patrones de diseño principales que se están discutiendo en la comunidad de desarrollo de Bitcoin:

1. Canales
2. Virtual UTXOs

En el patrón de canal, del que Lightning es el principal ejemplo, el protocolo progresa intercambiando transacciones pre-firmadas entre las partes que podrían ser minadas, pero que no están en el "camino feliz". Estas transacciones pre-firmadas dividen un UTXO entre las partes; Las transacciones se realizan cambiando repetidamente el saldo de esa división, con nuevas transacciones prefirmadas. Dado que habrá muchas transacciones válidas posibles diferentes que gasten el mismo UTXO, se necesita algún mecanismo de incentivo para asegurarse de que la transacción correcta sea la que realmente se extrae.

En el patrón de diseño Virtual UTXO (V-UTXO), del que Ark es el ejemplo más destacado, los V-UTXO se crean a través de covenants o acuerdos multipartitos, a través de la creación de transacciones que podrían minarse para retirar unilateralmente los fondos de V-UTXO poniéndolos en la cadena, pero que no están en el "camino feliz". En ese sentido, los V-UTXO son similares a los canales. Pero a diferencia de los canales, los esquemas V-UTXO realizan transacciones gastando los propios V-UTXO, en (conceptualmente) un solo⁶transacción pre-firmada.

El patrón de diseño del "camino feliz" es el uso de un camino de script de "todos los participantes están de acuerdo", como un multisig N-de-N; taproot está diseñado específicamente para este concepto, permitiendo que el camino clave sea un multisig N-de-N a través de musig. Suponiendo que todas las partes estén de acuerdo, el camino feliz permite gastar las monedas de manera eficiente (y privada).

Curiosamente, dado que las UTXOs virtuales son “reales” en muchos sentidos, es bastante fácil construir canales sobre las UTXOs virtuales simplemente creando UTXOs virtuales que, si se minan, llevarían a la creación de las UTXOs necesarias para los canales. En ese sentido, los esquemas de UTXO virtuales son una

capa ligeramente inferior a los canales.

Relámpago

El statu quo, implementado en producción como la Capa 2, principalmente basado en el normas de BOLTs. Lightning es una combinación de varias cosas, incluyendo canales Lightning y HTLCs, la red de enrutamiento P2P, enrutamiento de cebolla, estándares de factura, etc. Es importante destacar que Lightning no es un sistema de consenso, por lo que los diferentes elementos del 'sistema Lightning' no necesitan ser adoptados de la misma manera por todos los usuarios. Para el propósito de este artículo, cuando decimos 'Lightning', lo usaremos en el sentido amplio, incluyendo actualizaciones fácilmente previsibles a los protocolos Lightning (típicos) actuales que son ampliamente utilizados.

Como se ha comentado anteriormente, la característica clave de Lightning es su límite de escalabilidad para el usuario final, debido a la necesidad de tener al menos un UTXO por usuario. Dicho esto, para el elemento de enrutamiento "central" de Lightning (los nodos públicos de Lightning que enrutan la gran mayoría de las transacciones), estos límites de escalabilidad no son una gran preocupación, ya que Lightning funciona bien si hay muchos más usuarios finales que nodos de enrutamiento, porque cada canal público utilizado para el enrutamiento de pagos puede admitir fácilmente una gran cantidad de transacciones por segundo. Esta es también la razón por la que tantos futuros sistemas L2 esperan participar también en la red Lightning. También vemos esto en cómo los sistemas existentes que no son del todo L2 como Cashu dependen en gran medida de la red Lightning para ser realmente útiles: el uso principal de Cashu es probablemente enviar y recibir pagos Lightning.

Canales no interactivos

Esta construcción mejora los canales de Lightning al usar OP_CTV para reducir los requisitos de interactividad. Sin embargo, al no mejorar el límite de escala de 1-UTXO-por-usuario, no lo discutiremos más.

Fábricas de Canales

Aquí tenemos varias partes negociando una dirección multisig n-of-n única, junto con una transacción que gasta esa dirección multisig para crear n UTXO's diferentes dividiendo los fondos. A su vez, esos UTXO se utilizan para los canales de pago. Los canales se pueden utilizar con la misma seguridad que si se hubieran abierto directamente on-chain, porque en caso de que el estado del canal deba ponerse on-chain, la transacción dividida se puede minar. Esto potencialmente ahorra espacio on-chain cuando se cierran los canales, ya que las n partes pueden, en teoría, cerrar cooperativamente todos los nn canales a la vez.

Dado que las factorías de canales están negociando UTXO que podrían ser minados, pero no se espera que realmente sean minados en el camino feliz, son un ejemplo muy primitivo de V-UTXOs.

Las fábricas de canales por sí mismas no requieren ningún fork suave para ser posibles. Sin embargo, las fábricas de canales simples descritas anteriormente probablemente son imprácticas más allá de pequeños números de partes debido a la coordinación requerida para lograr realmente un beneficio de escalabilidad. Por lo tanto, propuestas de convenio como OP_Evicto CTV (a través de árboles de txout) tiene como objetivo permitir resultados más detallados donde se pueden obligar a partes individuales en la cadena, sin obligar a todos en la cadena a la vez.

Eltoo/LN-Simetría

Dado que Eltoo es un nombre terriblemente confuso, solo usaremos el nombre actualizado LN-Symmetry en el futuro.

Mientras que los canales de Poon-Dryja fomentan que el estado correcto se publique en la cadena castigando los estados incorrectos, LN-Symmetry permite que los estados incorrectos se actualicen con una transacción adicional. Esto tiene la ventaja de simplificar los canales Lightning al eliminar la complejidad de las penalizaciones. Sin embargo, es probable que esto sea una desventaja en escenarios que no son de confianza, ya que podría decirse que las sanciones son necesarias para desalentar el fraude.

LN-Symmetry necesita un soft-fork para habilitarSIGHASH_ANYPREVOUT, lo que es necesario para permitir que las transacciones estatales vuelvan a gastar otras transacciones estatales durante las actualizaciones.

Por sí misma, LN-Symmetry no ofrece mejoras de escalabilidad en los canales Lightning convencionales. Pero Los proponentes han argumentadoque hace que cosas como las fábricas de canales sean más fáciles de implementar.

ARK

Ark adopta un nuevo enfoque para la escalabilidad de transacciones: los salidas de transacciones no gastadas virtuales totalmente transferibles (V-UTXO), que se pueden combinar y dividir en átomos.⁷transacciones fuera de la cadena. En Ark, un coordinador central, el Proveedor de Servicios de Ark (ASP), proporciona V-UTXOs para usuarios con una duración definida, por ejemplo, 4 semanas. Estos períodos se conocen como rondas. Estos V-UTXOs se crean a través de pool txouts, uno por ronda, a través de algún tipo de mecanismo como CTV para permitir que una única txout en la cadena se comprometa con un árbol de V-UTXOs. La expiración de la ronda es cómo Ark logra una ventaja de escalado: al final de una ronda, el pool txout se desbloquea, lo que permite al ASP gastarlo unilateralmente con una sola firma en una transacción pequeña. Debido al tiempo de vencimiento de la ronda, los propios V-UTXOs expiran cuando caducan los pool txouts que los crean: los usuarios que poseen un V-UTXO deben gastar ese V-UTXO antes de que se alcance el tiempo de vencimiento del pool txout o ponerlo en la cadena (retiro unilateral).

Para realizar transacciones de V-UTXOs entre partes, el coordinador de Ark co-firma transacciones que gastan uno o más V-UTXOs, de manera que las transacciones solo son válidas si se crean uno o más V-UTXOs en una ronda diferente. En combinación con algunos límites de tiempo cuidadosos - ver la documentación de Ark para más detalles - esta dependencia es lo que hace que gastar V-UTXO's sea confiable: los V-UTXO's no se pueden reclamar en la cadena a menos que se creen nuevos V-UTXOs en una transacción de grupo diferente. Hay algunas formas potenciales de implementar esa dependencia. Pero los detalles exactos no son relevantes para los propósitos de este artículo.

Observa cómo esto significa que un ASP determinado tendrá muchas rondas activas diferentes sucediendo a la vez. Se crean nuevas rondas con frecuencia para permitir la transferencia de fondos en las rondas existentes. Pero las rondas existentes se superponen a las nuevas rondas, ya que generalmente expirarán después de las nuevas rondas y las nuevas transacciones de la piscina se creen.

Economía de Ark

Cuando se gasta un V-UTXO, el ASP debe proporcionar BTC coincidentes en una nueva transacción de grupo que representa una nueva ronda. Pero no pueden recuperar el valor del V-UTXO gastado hasta que expire la ronda. Por lo tanto, la economía de los gastos de V-UTXO tiene un costo de tiempo-valor del dinero, debido a la liquidez que el ASP tiene que proporcionar.

Específicamente, el costo se incurre cuando se gasta el V-UTXO. Mientras el V-UTXO no se gasta, representa un UTXO potencial muy real que podría ponerse en la cadena para retirar los fondos unilateralmente; el usuario es dueño de esos fondos. Sin embargo, para gastar el V-UTXO, el ASP debe crear una nueva transacción de salida de la piscina, utilizando fondos que el ASP obtiene de otro lugar, mientras que los fondos en el V-UTXO gastado no están disponibles para el ASP hasta que se alcance el tiempo de vencimiento.

Por lo tanto, gastar un V-UTXO requiere un préstamo a corto plazo, tomar prestados fondos para cubrir el intervalo de tiempo entre ahora y cuando la ronda expire. Esto significa que el costo de liquidez para gastar un V-UTXO en realidad disminuye a medida que el V-UTXO envejece y el tiempo de vencimiento se acerca, eventualmente —en teoría— alcanzando cero cuando la ronda finalmente expire.

Por último, recuerda que el coste de gastar un V-UTXO está relacionado con el tamaño total del V-UTXO gastado. No la cantidad pagada al destinatario. Esto significa que las billeteras destinadas a realizar transacciones de V-UTXO directamente (en lugar de administrar un V-UTXO con el fin de, por ejemplo, un canal de iluminación basado en V-UTXO), tienen que hacer concesiones en la forma en que dividen los fondos en V-UTXO. Un solo V-UTXO minimiza el costo del retiro unilateral, al tiempo que maximiza las tarifas de transacción basadas en la liquidez; dividir los fondos en muchos V-UTXO hace lo contrario. Esto es completamente diferente a la economía de las transacciones en cadena de Bitcoin o Lightning.

¿Cuál es el costo de liquidez? Al momento de escribir esto, la billetera Lightning Phoenix cobra una tarifa del 1% para reservar la liquidez del canal durante 1 año; en el peor de los casos, Phoenix tendría que comprometer sus fondos durante 1 año. Sin embargo, eso asume que la liquidez no se utiliza. Es bastante posible que el costo de capital para Phoenix sea en realidad más alto y que asuman que el cliente promedio utiliza su liquidez entrante en menos de un año. ¡Phoenix también gana dinero con las tarifas de transacción, potencialmente subsidiando la liquidez del canal! ¡Finalmente, Phoenix podría no ser rentable!

La tasa de los bonos del Tesoro de EE. UU. nos da otra estimación. Al momento de escribir esto, la tasa de los bonos del Tesoro a 3 meses es de aproximadamente el 5% anual. Dado que hay un argumento de que esta tasa está inflada debido a que los dólares estadounidenses son inflacionarios, asumiremos que el costo de la liquidez para los fondos denominados en BTC es del 3% anual para nuestro análisis.

Si el intervalo de redondeo es de 4 semanas, esto significa que una transacción comenzaría con un costo de liquidez de

eventualmente disminuyendo a cero. Suponiendo que el usuario intente transferir sus fondos a una nueva ronda dos semanas antes de que expire la ronda, el usuario está pagando aproximadamente un 1.5% al año en costos de liquidez para lograr la custodia propia de sus fondos. Por otro lado, si el usuario espera hasta el último momento⁸, el costo podría ser casi cero, a riesgo de perder la hora de vencimiento.

Los usuarios pueden no ver esto como un costo trivial. Y este costo asume que los costos fijos de cada ronda se han vuelto insignificantes al amortizar las tarifas de transacción y otros costos entre un gran número de participantes.

¿Y si los costos fijos no son tan insignificantes? Supongamos que el ASP tiene 1000 usuarios y las transacciones del grupo se crean una vez por hora en promedio. Durante un período de 4 semanas, eso equivale a 672 transacciones en cadena. ¡Lo que significa que simplemente para mantener sus fondos, los usuarios del ASP tienen colectivamente que pagar casi tantas transacciones como usuarios! Probablemente les resultaría más barato a todos abrir sus propios canales de Lightning, incluso aunque el ASP les exija esperar una hora entera para una confirmación.

Inicializando Ark

Un nuevo ASP con pocos usuarios se enfrenta a un dilema: o bien los redondeos de ASP ocurren con poca frecuencia, y los usuarios tienen que esperar mucho tiempo para que la ronda propuesta reúna suficientes V-UTXOs para lograr una reducción útil de escalado y de tarifas de transacción. O bien, las transacciones de la piscina de ASP ocurren con frecuencia, con altas tarifas de transacción pagadas por usuario. Como se mostró en la sección anterior, puede requerir muchos usuarios para amortizar las rondas frecuentes y sus txouts de piscina subyacentes.

Debido a que las rondas expiran, este problema es continuo, incluso peor que el enfrentado por los canales de Lightning: al menos un canal de Lightning puede seguir siendo útil indefinidamente, permitiendo que un canal se abra ahora y se amortice gradualmente durante muchos meses. En segundo lugar, debido a que las rondas expiran, hay menos flexibilidad en cuanto a cuándo crear las nuevas salidas de tx que respalden estas rondas: si las tarifas son altas durante una o dos semanas, los usuarios cuyas salidas de tx de la agrupación están expirando no tienen otra opción que pagar (colectivamente) esas tarifas altas para mantener la custodia de sus fondos. Con los canales de Lightning, hay mucha más flexibilidad en cuanto a cuándo abrir realmente un canal.

Si bien los autores de Ark inicialmente imaginaron un escenario muy optimista en el que nuevas rondas cada pocos segundos, el arranque inicial probablemente tendrá que ocurrir con casos de uso que pueden permitirse esperar varias horas para que se confirme una transacción de Ark, si las tarifas de transacción no están subsidiadas.

Interactividad

Non-custodial Ark es un protocolo altamente interactivo: dado que sus V-UTXO caducan, tiene plazos estrictos para interactuar con su ASP, o de lo contrario el ASP podría optar por tomar sus fondos. Esta interactividad tampoco se puede externalizar: mientras que Lightning tiene watchtowerspara desalentar a las contrapartes de intentar engañarte, incluso si tu canal no ha estado en línea, los propietarios de monedas Ark deben usar sus propias claves privadas para actualizar los fondos sin confianza. Lo más parecido posible en Ark a los watchtowers sería firmar transacciones que permitan a una torre de vigilancia retirar unilateralmente sus fondos en la cadena hacia el tiempo de expiración, lo cual tiene un costo significativo de tarifa de transacción.

Considera qué sucede con un V-UTXO si el propietario se desconecta: después de que expire la ronda, el ASP necesita recuperar los fondos para recuperar su liquidez para rondas posteriores. Si un propietario de V-UTXO se desconecta, poner ese V-UTXO en la cadena tiene costos significativos de transacción, ya que el ASP ahora necesita recuperar fondos en múltiples niveles del árbol de V-UTXO. El ASP puede recrear los V-UTXO no gastados en una nueva ronda. Pero esto no es confiable desde la perspectiva de los propietarios de V-UTXO, ya que no pueden gastar esos V-UTXO sin obtener datos⁹desde el ASP. El ASP también podría simplemente registrar V-UTXOs no gastados como saldo custodial. ¡O tal vez incluso tener una política de incautar los fondos!

Personalmente, sospecho que, dado el costo no trivial de la autocustodia en Ark, muchos usuarios elegirán ASP con una política de transferir fondos a una nueva ronda y simplemente aceptarán el potencial de fraude al final de cada ronda. Esto es más barato que mover proactivamente sus fondos lo suficientemente temprano como para garantizar la seguridad en caso de que, por ejemplo, no enciendan su teléfono a tiempo para que su billetera mueva los fondos a una nueva ronda.

Advanced Ark

Podría ser factible reducir los requisitos de liquidez de Ark a través de convenios más avanzados, si es típico que la liquidez se agote en algún momento de una ronda. Por ejemplo, supongamos que se ha utilizado el 50% del valor total de V-UTXO en una txout de la piscina. Si el ASP pudiera recuperar solo esa parte de la txout de la piscina de la ronda, podrían recuperar la liquidez más rápidamente, reduciendo los costos generales de liquidez. Aunque no se han publicado propuestas concretas sobre cómo hacer esto, parece que debería ser posible con los convenios Sufficiently Advanced™. Lo más probable es que sea a través de algún tipo de soft-fork de reactivación de scripts que agregue muchos opcodes útiles a la vez.

Del mismo modo, a través de los convenios suficientemente avanzados™, toda la estructura del árbol de txout podría reemplazarse con algún tipo de esquema de retiro continuo, lo que podría ofrecer ahorros de espacio. Cubriremos esto en una sección posterior, ya que esta técnica es potencialmente útil para otros esquemas.

La cuestión de la custodia al final de la ronda es otro caso en el que los convenios suficientemente avanzados™ podrían resolver un problema: un convenio, en particular, un convenio a prueba de ZK, podría obligar al ASP a recrear todos los V-UTXO no gastados en la siguiente ronda, eliminando el problema de que la custodia vuelva a ellos al final de una ronda. Si bien es probable que esto no sea confiable, ya que es probable que el usuario necesite algunos datos del ASP para gastar su V-UTXO en la nueva ronda, podría evitar que el ASP se beneficie financieramente del fraude contra los usuarios fuera de línea.

Pago de comisiones on-chain en retirada unilateral

Similar a Lightning, la economía de pago de tarifas en cadena y el valor real de un V-UTXO después de las tarifas determinan si el uso de Ark cumple con nuestra definición de una Capa 2 mediante el retiro unilateral o el fraude que no beneficia al ASP. Discutiremos los detalles de esto más adelante cuando hablemos del patrón de diseño del árbol de txout.

Rollups de Validez

Una gran clase de construcciones similares a sidechain, generalmente propuestas para usar diversas formas de tecnología de prueba de conocimiento cero (ZK) para hacer cumplir las reglas de la cadena. La tecnología de prueba de ZK es la diferencia crítica entre la tecnología de consolidación de validez y otras formas de sidechain: si el esquema de prueba de ZK funciona, la validez de las transacciones puede garantizarse mediante matemáticas en lugar de confiar en un tercero. El aspecto de "conocimiento cero" de una prueba de ZK en realidad no es un requisito en este caso de uso: está perfectamente bien si la prueba "filtra" información sobre lo que está probando. Simplemente sucede que la mayoría de los esquemas matemáticos para esta clase de prueba resultan ser pruebas de conocimiento cero.

Desde el punto de vista de Bitcoin, un esquema de rollup de validez requiere un convenio, ya que queremos poder crear UTXO para el esquema que solo se pueden gastar si se siguen las reglas del esquema. No se trata necesariamente de un proceso descentralizado. De hecho, muchos esquemas de acumulación de validez están completamente centralizados; La prueba de acumulación demuestra que el secuenciador de transacciones centralizado siguió las reglas para una secuencia particular de transacciones.

En cuanto al pacto... La tecnología de Prueba de Conocimiento Cero sigue siendo un campo muy nuevo, con avances que se realizan con frecuencia. Por lo tanto, es muy poco probable que veamos que se agreguen códigos de operación a Bitcoin que validen directamente esquemas específicos de pruebas de conocimiento cero. En cambio, generalmente se acepta que los esquemas específicos utilizarían códigos de operación más generales, en particular OP_CAT, para validar pruebas de conocimiento cero a través de scripts. Por ejemplo, StarkWareescampañaque se adopte OP_CAT.

Los rollups de validez son un tema potencialmente grande, con tantos proyectos de baja sustancia/alto entusiasmo, que no discutiremos más allá de señalar qué opcodes potencialmente hacen viable esta clase de diseño.

BitVM

A grandes rasgos, BitVM es una forma de construir un canal Lightning entre dos partes, de modo que las reglas del canal Lightning se hagan cumplir mediante una prueba de conocimiento cero. Dado que en realidad no necesita que se implementen convenios en Bitcoin hoy en día, y debido a que no se puede usar directamente para crear un sistema L2 que escale más allá del límite de 1-UTXO por usuario, no lo discutiremos más.

Canales Jerárquicos

Canales jerárquicos¹⁰tiene como objetivo hacer que el cambio de tamaño del canal sea rápido y económico: “Los canales jerárquicos hacen por la capacidad del canal lo que LN hace por bitcoin”. Sin embargo, aún no superan fundamentalmente el límite de 1 UTXO por usuario. Además, de todos modos, no requieren cambios en el protocolo de Bitcoin. Por lo tanto, no vamos a discutirlos más. ¡Sus defensores simplemente deberían implementarlos! No necesitan nuestra autorización.

CoinPool

CoinPool permite que varios usuarios compartan una sola UTXO, transfieran fondos entre diferentes usuarios y retiren unilateralmente. La propuesta de papel de CoinPool requiere tres nuevas características de softfork, SIGHASH_ANYPREVOUT, un SIGHASH_GROUP que permite que una firma se aplique solo a UTXOs específicos y un OP_MerkleSub para validar la eliminación de ramas específicas de un árbol de merkle; esto último también se podría lograr con OP_CAT.

Por el momento, el desarrollo de CoinPool parece haberse estancado, y el último compromiso con el sitio web de especificaciones fue hace dos años.

Red Enigma

Si bien se me pidió que cubriera la Red Engima, parece haber una falta de documentación sobre lo que realmente propone. entrada de blog hace muchas afirmaciones; el página del MITestá vacío. Como la publicación en el blog no deja muy claro qué es lo que se supone que está sucediendo, no lo discutiremos más.

Consideraciones de la Mempool

La política actual de mempool en Bitcoin Core no es ideal para los sistemas de Capa 2. Aquí repasaremos algunos de los principales desafíos que enfrentan y posibles mejoras.

Anclaje de Transacción

En última instancia, una explotación económica, los ataques de fijación de transacciones, se refieren a una variedad de situaciones en las que alguien puede intencionalmente (o involuntariamente) hacer que sea difícil obtener una transacción deseada minada debido a la transmisión previa de una transacción conflictiva que no se mina. Esto es una explotación económica, porque en una verdadera situación de fijación de transacciones, existe una transacción deseable de la que los mineros obtendrían ganancias si la minaran; la transacción conflictiva de fijación no se mina en un tiempo razonable, si es que se mina en algún momento.

El ejemplo más simple de anclaje proviene del hecho de que sin RBF completo, el reemplazo de transacciones se puede desactivar. Por lo tanto, podemos tener una transacción de tarifa baja, con el reemplazo desactivado, que no se minará pero no se puede reemplazar. Esencialmente, el 100% de la potencia de hash ha solucionado este problema al habilitar el RBF completo y, al momento de escribir este artículo, el RBF completo debería estar habilitado de forma predeterminada en la próxima versión de Bitcoin Core (después de 11 años de esfuerzo!).

Eso deja la fijación de la Regla #3 de BIP-125, el único problema de fijación restante que es relevante para los protocolos multiparte L2 y no se ha corregido en Bitcoin Core. Para referencia, la Regla #3 de BIP-125 establece lo siguiente:

Se requiere una transacción de reemplazo para pagar la tarifa absoluta más alta (no

tasa de tarifa justa) que la suma de las tarifas pagadas por todas las transacciones que se reemplazan.

Esta regla puede ser explotada mediante la difusión de una transacción de anclaje grande y de baja tasa de comisión que gasta las salidas relevantes para el protocolo multiparte (alternativamente, un grupo de transacciones). Dado que la transacción tiene una tasa de comisión baja, no será minada de manera oportuna, si es que alguna vez lo es. Sin embargo, dado que tiene una tarifa total alta, reemplazarla con una transacción diferente es poco rentable.

La fijación de la regla # 3 se soluciona con bastante facilidad a través de tarifa-de-reemplazo-por-feey esta solución funciona en todas las situaciones. Desafortunadamente, no está claro si RBFR será adoptado por Core en un futuro cercano, ya que han invertido una cantidad sustancial de esfuerzo en una solución parcial inferior. Transacciones TRUC/V3.

Pago de comisión: RBF, CPFP, SIGHASH_ANYONECANPAY, Anclas y Patrocinio

Dado que las tarifas son impredecibles, es difícil pagar de manera confiable y económica en situaciones en las que las transacciones se firman previamente. El estándar de oro para el pago de tarifas es usar RBF, comenzando con una estimación inicial "baja" y reemplazando la transacción con versiones de tarifas más altas según sea necesario hasta que se extraiga. Por ejemplo, el software de calendario OpenTimestamps ha utilizado RBF de esta manera durante años, y LND agregó soporte para RBF consciente de la fecha límite en v0.18.

RBF es el estándar de oro para el pago de tarifas porque es el más eficiente en casi todo el espacio de bloques¹¹situaciones: las transacciones de reemplazo no necesitan entradas o salidas adicionales, en comparación con lo que habría sido necesario si se hubiera adivinado la tarifa correcta en el primer intento.

La eficiencia es importante, porque las ineficiencias en el pago de las tarifas pago de tarifa fuera de banda una fuente rentable de ingresos para los grandes mineros; Los mineros más pequeños y descentralizados no pueden beneficiarse de los pagos de tarifas fuera de banda debido a la impracticabilidad e inutilidad de pagar a un minero pequeño para que confirme una transacción. El pago de tarifas fuera de banda también parece invitar a problemas de AML/KYC: en la actualidad, la mayoría de los sistemas de pago de tarifas fuera de banda actualmente disponibles en este momento requieren algún tipo de proceso AML/KYC para realizar un pago de tarifas, con la notable excepción de la acelerador de mempool.space, que al momento de escribir esto (Agosto de 2024), acepta Lightning sin necesidad de una cuenta.

Para utilizar RBF directamente en situaciones con transacciones prefirmadas, es necesario prefirmar variantes de tarifas que cubran todo el rango de tarifas potenciales. Si bien esto es bastante factible en muchos casos, ya que el número de variantes necesarias suele ser pequeño.¹², hasta ahora el protocolo Lightning de producción - y otros protocolos propuestos - han optado en cambio por usar Child-Pays-For-Parent (CPFP), generalmente a través de salidas de anclaje.

La idea detrás de una salida de ancla es agregar una o más salidas a una transacción con un valor mínimo o nulo, con la intención de pagar tarifas a través de CPFP al gastar esas salida(s) en transacciones secundarias. Por supuesto, esto es muy ineficiente cuando se aplica a protocolos como LN que tienen transacciones en la cadena pequeñas, casi sin valor.duplicando el tamaño total de una transacción de compromiso LN que utiliza una salida de ancla efímera. Sería menos preocupante cuando se aplicaran protocolos que hicieran uso de transacciones más grandes, como cualquier cosa que usara OP_CAT para implementar convenios.

Un problema menos obvio con las salidas de anclaje es la necesidad de mantener UTXO adicionales para pagar las tarifas. En una aplicación "cliente" típica, esto puede ser una carga general significativa, ya que sin las salidas de anclaje a menudo no hay necesidad de mantener más de un UTXO. De hecho, es probable que algunas billeteras Lightning existentes centradas en el consumidor sean vulnerables al robo por parte del lado remoto del canal en entornos de tarifas altas debido a la incapacidad de pagar las tarifas.

SIGHASH_ANYONECANPAY se puede utilizar para el pago de comisiones en algunos casos al permitir la adición de insumos adicionales a las transacciones firmadas; SIGHASH_SINGLE también permite agregar salidas. Lightning lo utiliza para transacciones HTLC. En este momento, esta práctica puede ser vulnerable a la fijación de transacciones si no se maneja con cuidado.¹³, ya que un atacante podría agregar una gran cantidad de entradas y/o salidas a una transacción para crear un pin de alta tarifa/tasa de baja tarifa. RBFR soluciona este problema; el enfoque utilizado en las transacciones TRUC/V3 no puede solucionar este problema. Este estilo de pago de tarifas no es tan eficiente como RBF. Pero puede ser más eficiente que las salidas de anclaje.

Finalmente, ha habido una variedad de propuestas de soft-fork para añadir un patrocinio de tarifassistema para el protocolo Bitcoin. Esto permitiría que las transacciones declaren dependencias de otras transacciones, de modo que la transacción patrocinadora solo se podría minar si también se mina la transacción patrocinada (probablemente en el mismo bloque). Esto podría ser mucho más eficiente que un CPFP tradicional, ya que la transacción patrocinadora podría declarar esa dependencia utilizando significativamente menos vbytes que el tamaño de una entrada de transacción.

Ciclismo de reemplazo

El ataque de reemplazo de ciclismo¹⁴aprovecha la sustitución de transacciones para intentar reemplazar una transacción L2 deseada el tiempo suficiente para que en su lugar se mine una no deseada. Básicamente, los ataques de ciclismo de reemplazo son, para el atacante, una alternativa a las técnicas de anclaje de transacciones en el sentido de que buscan evitar que una transacción deseada y honesta se mine el tiempo suficiente para permitir que en su lugar se mine una transacción no deseada y deshonesta. A diferencia de los ataques de anclaje de transacciones, un ataque de ciclismo de reemplazo no puede ocurrir por accidente.

El ejemplo canónico es contra un contrato de tiempo bloqueado con hash (HTLC). Si bien es fácil pensar en un HTLC como un contrato para permitir que una transacción se gaste a través de la revelación de una imagen previa o a través de un tiempo de espera. En realidad, debido a las limitaciones de las secuencias de comandos de Bitcoin, un HTLC permite que una transacción siempre se gaste a través de la revelación de una imagen previa, y luego después de un tiempo de espera, adicionalmente a través del mecanismo de tiempo de espera.

El ciclismo de reemplazo aprovecha esto utilizando la preimagen después de que expire el tiempo de espera, para reemplazar la transacción que intenta canjear la salida HLTC a través del mecanismo de tiempo de espera sin que la víctima aprenda la preimagen. Un ataque exitoso de ciclismo de reemplazo hace esto el tiempo suficiente para que caduque el HTLC de un canal diferente.

Un desafío principal para aprovechar de manera rentable el ciclo de reemplazo es que cada ronda de reemplazo cuesta dinero. Una implementación de Lightning consciente de los plazos gastará tarifas cada vez más altas tratando de gastar la salida HTLC vencida antes de que venza la siguiente salida HTLC a su vez. En segundo lugar, cualquiera puede derrotar el ataque simplemente volviendo a transmitir la transacción reemplazada.¹⁵una vez que se haya completado el ciclo de reemplazo.

Al igual que con la fijación de transacciones, el ciclo de reemplazo también es una hazaña económica para los mineros. Al final de cada ciclo de reemplazo, existe una transacción que se ha eliminado de los mempools, pero que es totalmente válida y podría ser minada si los mineros todavía la tuvieran en sus mempools.

Patrones de características y Forks suaves

Ahora que le hemos dado una visión general de la variedad de sistemas L2 dependientes del pacto y desafíos de la mempool, vamos a intentar destilar esa información a un conjunto de características notable del fork suave (principalmente nuevos opcodes) y patrones de diseño que estos sistemas L2 comparten. Para las propuestas de soft-fork, también discutiremos los riesgos técnicos específicos de la propuesta y los desafíos de implementar cada propuesta.

OP_Expire

Empezaremos por esto. Se propuso OP_Expire¹⁶como una forma sencilla de eliminar el ataque de ciclo de reemplazo al solucionar el problema en la fuente: el hecho de que las HTLC pueden gastarse de dos formas diferentes a la vez. En el contexto de los sistemas de Capa 2, esto es relevante para cualquier cosa que utilice un mecanismo similar a HTLC, y posiblemente otros casos de uso. OP_Expire haría posible que una salida de transacción sea no gastable después de cierto punto en el tiempo, lo que permitiría que las condiciones de gasto de HTLC sean un verdadero O exclusivo en lugar de un "O de programadores".

Un soft-fork real de OP_Expire probablemente consistiría en dos características, similar a cómo el OP_CheckLockTimeVerify y OP_CheckSequenceVerifylos opcodes se dividen en dos partes:

1. Un campo de altura de vencimiento para transacciones, probablemente implementado en el anexo de taproot.
2. Un código de operación OP_Expire que comprueba que la altura de caducidad está establecida en al menos la altura deseada.

Si bien OP_Expire en sí mismo apenas califica como un pacto, parece ser útil para muchos sistemas L2 dependientes de covenants. Sin embargo, puede que no sea lo suficientemente útil dado que el ciclo de reemplazo también puede ser mitigado por la retransmisión altruista.¹⁵

Un desafío muy notable al implementar y usar OP_Expire son las reorganizaciones: la comunidad técnica de Bitcoin, comenzando con Satoshi¹⁷, ha tratado de asegurarse de que el protocolo de consenso de Bitcoin esté diseñado de tal manera que después de una reorganización profunda, las transacciones previamente minadas puedan ser minadas en nuevos bloques. Este principio de diseño intenta evitar el escenario de pesadilla de que un gran número de monedas confirmadas se vuelvan permanentemente inválidas, y así las personas que dependen de esas monedas pierdan dinero, si una falla de consenso conduce a una reorganización grande.

En caso de una reorganización importante, las transacciones que utilizan la expiración podrían volverse no minables debido a que se alcanza su altura de caducidad. La propuesta OP_Expire propone mitigar este problema tratando las salidas de las transacciones que utilizan la expiración de manera similar a las transacciones de coinbase, haciéndolas también no gastables durante aproximadamente 100 bloques.

Una barrera significativa para implementar la expiración de transacciones es llegar a un consenso sobre si este compromiso es aceptable o incluso necesario. Los tipos de transacciones donde OP_Expire sería útil ya implican plazos bastante largos donde los fondos del usuario están congelados. Añadir aún más tiempo a estos plazos no es deseable. Además, las dobles gastas siempre han sido otra forma de invalidar monedas después de una reorganización: con el aumento del uso de RBF y el uso propuesto de salidas de ancla sin clave, ¿la expiración de la transacción haría una diferencia significativa?

SIGHASH_ANYPREVOUT

BIP-118propone dos nuevos modos de hash de firma, ninguno de los cuales se compromete al UTXO específico que se gasta. SIGHASH_ANYPREVOUT, que (esencialmente) se compromete al scriptPubKey en su lugar, y SIGHASH_ANYPREVOUTANYSCRIPT, que permite cualquier script. Como se discutió anteriormente, esto fue originalmente propuesto para su uso por LN-Symmetry para evitar la necesidad de firmar por separado cada estado de canal previo que pueda necesitar ser reaccionado.

SIGHASH_ANYPREVOUT también puede ser potencialmente útil en casos en los que queremos usar variantes de tarifas RBF prefirmadas en conjunto con transacciones prefirmadas, ya que el hecho de que la firma ya no depende de un txid específico evita unexplosión combinatoria de variantes de tarifasSin embargo, la propuesta actual de BIP-118 no aborda este caso de uso y puede ser incompatible debido al hecho de que se propone que SIGHASH_ANYPREVOUT también se comprometa con el valor del UTXO.

Una objeción inicial a SIGHASH_ANYPREVOUT fue la idea de que las billeteras se meterían en problemas al usarlo de manera inapropiada. El problema es que una vez que se ha publicado una sola firma SIGHASH_ANYPREVOUT, se puede usar para gastar cualquier txout con el script especificado. Por lo tanto, si se crea accidentalmente una segunda salida con el mismo script, SIGHASH_ANYPREVOUT permite un ataque de repetición trivial para robar esas monedas. Sin embargo, dado que hay tantas otras armas de pie inherentes a las billeteras y las implementaciones de L2, esta preocupación parece haber desaparecido.

Por el momento, la comunidad técnica general parece estar razonablemente positiva sobre la implementación de BIP-118. Sin embargo, como se discutió anteriormente en nuestra discusión sobre LN-Symmetry, hay un debate sobre si su caso de uso principal, LN-Symmetry, es realmente una buena idea.

OP_CheckTemplateVerify

Nuestra primera propuesta de opcode específico de covenant, OP_CheckTemplateVerify — o “CTV” como comúnmente se le conoce — tiene como objetivo crear un opcode de covenant muy específico y restringido haciendo exactamente una cosa: hashear la transacción de gasto de una manera especificada que no se compromete con los UTXOs de entrada, y verificar el resumen resultante contra el elemento superior de la pila. Esto permite que la transacción de gasto esté restringida de antemano, sin hacer que las restricciones verdaderas de covenant recursivo sean posibles.

¿Por qué no son posibles los convenios recursivos en CTV? Porque las funciones hash: CTV verifica la transacción de gasto con un hash de plantilla, y no hay forma¹⁸de crear una plantilla que contenga un CTV con un hash de sí mismo.

Dicho esto, esto no es necesariamente una limitación real: puede cifrar fácilmente una cadena de hashes de plantillas de CTV a una profundidad de decenas de millones de transacciones en solo unos segundos en una computadora moderna. Con bloqueos temporales de nSequence relativosy el tamaño de bloque limitado, en realidad, llegar al final de una cadena podría fácilmente tomar miles de años.

La propuesta actual CTV en BIP-119solo tiene un modo de hash, conocido como DefaultCheckTemplateVerifyHash, que básicamente se compromete a cada aspecto de la transacción de gasto en el hash de la plantilla. Desde un punto de vista práctico, esto significa que en muchas circunstancias, el único mecanismo disponible para el pago de tarifas será CPFP. Como se mencionó anteriormente, este es un problema potencial debido a que hace que el pago de tarifas fuera de banda sea un ahorro de costos no trivial en casos en los que las transacciones que utilizan CTV son pequeñas.

Es justo decir que CTV cuenta con el apoyo más amplio entre la comunidad técnica de cualquier propuesta de opcode de convenio debido a su relativa simplicidad y amplio rango de casos de uso.

LNHANCE

Una propuesta para implementar CTV es combinarlo con dos opcodes más, OP_CheckSigFromStack(Verify) y OP_InternalKey. El problema es que, al momento de escribir esto, la documentación en esa pull-req y los BIP asociados simplemente no son suficientes para argumentar a favor o en contra de esta propuesta. Los BIP carecen por completo de la razón por la que se espera que los opcodes hagan algo en ejemplos del mundo real, y mucho menos en scripts de ejemplo detallados.

Si bien los autores probablemente tengan buenas razones para su propuesta, la responsabilidad recae sobre ellos para explicar realmente esas razones y justificarlas adecuadamente. Por lo tanto, no vamos a discutirlo más.

OP_TXHASH

Al igual que la CTV, esta propuesta logra una funcionalidad de convenio no recursivo mediante el hash de los datos de la transacción de gasto. A diferencia de CTV, la propuesta de TXHASH proporciona un mecanismo de "selector de campo", lo que permite flexibilidad en la forma exacta en que se restringe la transacción de gasto. Con esta flexibilidad se consiguen dos objetivos principales:

1. Habilitar la adición de tarifas a una transacción sin romper un protocolo multi-tx.
2. Protocolos multiusuario donde los usuarios solo restringen sus propias entradas y salidas.

El principal problema con OP_TXHASH es que el mecanismo de selector de campo agrega bastante complejidad, lo que hace que la revisión y prueba sean desafiantes en comparación con la propuesta CTV mucho más simple. En este momento, simplemente no ha habido mucho análisis de diseño sobre cuán beneficioso sería realmente el mecanismo de selector de campo, o cómo exactamente se usaría. Por lo tanto, no lo discutiremos más.

OP_CAT

El operador de concatenación, que concatena los dos elementos principales de la pila y empuja el resultado concatenado nuevamente a la pila. Bitcoin se envió originalmente con OP_CAT habilitado. Pero Satoshilo eliminó silenciosamente en 2010, probablemente debido al hecho de que la implementación inicial era vulnerable a ataques DoS debido a la falta de restricciones en el tamaño del elemento de script resultante. Considere el siguiente script:

DUP CAT DUP CAT...

Sin una restricción de tamaño de elemento, cada iteración DUP CAT duplica el tamaño del elemento superior de la pila, utilizando eventualmente toda la memoria disponible.

La concatenación es suficiente para implementar muchos tipos de convenios, incluidos los convenios recursivos, siguiendo estos pasos:

1. Ensamble una transacción parcial, sin datos de testigo, en la pila con una o más invocaciones de OP_CAT (y cualquier lógica específica del contrato que sea necesaria).
2. Validar que la transacción en la pila coincida con la transacción de gasto.

Resulta que, por abusando de las matemáticas de las firmas de Schnorr, es posible realizar el segundo paso con OP_CheckSig mediante firmas cuidadosamente construidas. Sin embargo, es más probable que un soft-fork de OP_CAT se combine con OP_CheckSigFromStack, lo que permitiría realizar el segundo paso validando que una firma en la pila sea una firma válida para la transacción¹⁹, y luego reutilizando esa misma firma con OP_CheckSig para validar que la transacción de gasto coincida.²⁰

El hecho de que solo necesitemos ensamblar la transacción sin datos de testigo es un punto clave: el convenio solo necesita validar lo que hace la transacción - sus entradas y salidas - no los datos de testigo (si los hay) que realmente la hacen válida.

Además de los límites de tamaño del script del módulo, la combinación de OP_CAT y OP_CheckSigFromStack es suficiente para construir muchos tipos de acuerdos, incluyendo acuerdos recursivos. En comparación con soluciones más eficientes como CTV, es más costoso. ¡Pero la diferencia de costos es menor de lo que esperaría!

Hablando en términos generales, usar OP_CAT para hacer esto requiere que toda la parte no testigo de la transacción de gasto se coloque en la pila a través del testigo. Para casos de uso típicos de CTV, como los árboles de txout, la transacción de gasto no tendrá datos de testigo en absoluto. Dado que el espacio de testigo tiene un descuento del 75%, eso aumenta nuestra tarifa de transacción efectiva para la transacción secundaria solo en un 25%. ¡No está mal!

¿Es OP_CAT Demasiado Poderoso?

Este es probablemente el obstáculo político y técnico más grande para implementar OP_CAT: es muy difícil predecir qué casos de uso serán posibles gracias a OP_CAT. Y una vez que el "gato" está fuera de la bolsa, es muy difícil volver a meterlo.

Un gran ejemplo es cómo se afirma que OP_CAT es suficiente para permitir una eficiencia y seguridad razonableVerificación STARK a implementarse en el script de Bitcoin. Dado que los STARK pueden demostrar declaraciones extremadamente generales, hacer posible implementar STARK de manera eficiente tiene ramificaciones significativas que van más allá del alcance de los sistemas L2, ya que permitiría construir muchos sistemas diferentes sobre Bitcoin. Un argumento sólido en contra de OP_CAT es que estos casos de uso pueden no ser buenos en general para los usuarios de Bitcoin.

La creación de un Valor Extraíble del Minero centralizador dañino es un problema potencial clave,llamado “MEV que es maLigno” (MEVil) por Matt Corallo. En resumen, MEVil es cualquier circunstancia en la que los grandes mineros/pools pueden extraer valor adicional mediante el empleo de sofisticadas estrategias de minería de transacciones, más allá de simplemente maximizar las tarifas totales, que no son prácticas para que los mineros/pools más pequeños las adopten. La complejidad de los posibles instrumentos financieros que podrían crearse con OP_CAT hace que sea muy difícil descartar MEVil. Ya ha aparecido una cantidad significativa de MEVil en Bitcoin desde los protocolos de subasta de tokens; afortunadamente, ese caso específico fue derrotado mediante la adopción de RBF completo.

Además del potencial de MEVil, hay muchos otros casos de uso concretos de OP_CAT que son potencialmente perjudiciales. Por ejemplo, la propuesta Drivechains ha sido revisado aquí, y se considera ampliamente perjudicial para Bitcoin. Es se cree que es posiblepara implementar Drivechain con OP_CAT. Otro ejemplo son las propuestas de token como los Activos Taproot. Si bien en general es imposible evitar que se implementen con validación del lado del clienteExisten propuestas para implementarlas con OP_CAT de manera potencialmente más atractiva para los usuarios finales, pero también utilizando mucho más espacio de bloque, lo que podría superar potencialmente las transacciones de Bitcoin “legítimas”. Estos casos de uso también pueden plantear problemas legales debido a la frecuencia con la que se utilizan los protocolos de tokens para el fraude financiero.

Hashing incremental

Para los convenios, OP_CAT se utilizaría principalmente para concatenar datos, y luego hashearlos. Otra forma de lograr este mismo objetivo es con algún tipo de opcode de hasheo incremental que tome un SHA256 midstate de algún tipo, y hashee más datos en él; SHA256 opera en bloques de 64 bytes. Hay muchos diseños posibles para opcodes de hasheo incremental.

Una decisión de diseño importante es si exponer o no los bytes de estado medio reales en la pila en alguna forma canónica, o representarlos en algún nuevo tipo de elemento de pila opaco cuyo valor de byte real no se puede manipular directamente. SHA256 se especifica para un vector de inicialización particular y fijo, y parece desconocido si las propiedades criptográficas de SHA256 siguen siendo válidas si se permiten estados medios/vector de inicialización arbitrarios.

Por supuesto, dado que el hash incremental puede hacer más o menos lo que OP_CAT puede hacer, solo que de manera más eficiente, comparte todas las preocupaciones sobre OP_CAT ser demasiado poderoso.

Renacimiento del guion

OP_CAT fue uno de los 15 opcodes que Satoshi deshabilitó. Además de restaurar OP_CAT, Rusty Russell está proponiendo²¹ para restaurar esencialmente el script de Bitcoin a la "Visión Original de Satoshi" volviendo a habilitar la mayoría de esos códigos de operación, agregando límites de DoS y potencialmente agregando algunos más en la misma bifurcación suave. En particular, es probable que se produzca un OP_CheckSigFromStack.

Si bien OP_CAT por sí solo hace posible los convenios (recursivos), una completa "revitalización de secuencias de comandos" haría posibles convenios más sofisticados, y mucho más fáciles de implementar, ya que las partes de la transacción de gasto podrían manipularse directamente. Por ejemplo, podrías imaginar un guion de convenio que utiliza opcodes aritméticos para asegurar que el valor total de los txouts en la transacción se adhiera a alguna propiedad deseada.

Una vez más, el resurgimiento del script plantea todas las mismas preocupaciones, y más, sobre ser demasiado poderoso que OP_CAT por sí solo.

Simplicidad

Similar a Script Revival, Simplicity es relevante para las Capa 2 y los convenios al hacer posible hacer cualquier cosa. A diferencia de Script Revival, un soft-fork de Simplicity agregaría un lenguaje de programación completamente nuevo al sistema de scripting de Bitcoin basado en nueve operadores primitivos conocidos como combinadores.

En la práctica, Simplicity es tanto demasiado simple como no simple en absoluto. Los combinadores primitivos son tan ridículamente de bajo nivel que operaciones básicas como la adición tienen que implementarse laboriosamente desde cero; Simplicity en crudo sería excepcionalmente verboso en la práctica. Por lo tanto, cualquier uso real de Simplicity haría uso de un sistema de sustituciones de código, similar a las llamadas de funciones de biblioteca, conocido como jets. Esto plantea un problema práctico/político: ¿cómo se decide qué aviones implementar? Lo más probable es que los jets se implementen en C++, como cualquier otro código de operación, lo que requeriría una bifurcación suave para cada nuevo jet.

OP_FancyTreeManipulationStuff

Hay una gran variedad de códigos de operación relativamente especializados que se han propuesto para realizar la manipulación de árboles de una manera eficiente en cuanto al espacio para las propuestas L2 dependientes del pacto. Por ejemplo, los Coinpools han propuesto ambas cosas TAPLEAF_UPDATE_VERIFY y OP_MERKLESUB, ambos de los cuales manipulan árboles de taproot de formas necesarias para la propuesta de Coinpools, y la MATTLa propuesta ha propuesto un opcode OP_CheckContractVerify que, básicamente, verifica afirmaciones sobre árboles de merkle.

A los efectos de este artículo, no es necesario entrar en detalles sobre cada una de estas muchas propuestas. Más bien, podemos hablar de ellos como un grupo: todos son propuestas relativamente específicas para cada caso de uso que hacen posible una clase de L2, idealmente sin efectos secundarios no deseados. Todos tienen la ventaja de la eficiencia: todos utilizan menos espacio de bloque que lograr el mismo objetivo con códigos de operación más genéricos, como la manipulación de OP_CAT. Pero todos ellos tienen la desventaja de añadir complejidad al sistema de scripts, para un caso de uso potencialmente especializado.

El mismo dinámico ocurriría si Bitcoin adoptara el sistema de scripting Simplicity. El equivalente a los opcodes en Simplicity es agregar un jet para un patrón comúnmente utilizado. Nuevamente, implementar jets para operaciones específicas de caso de uso como la manipulación de árboles tiene pros y contras similares a la implementación de opcodes complejos para operaciones específicas de caso de uso.

Piscinas de Fondos

Todos los sistemas L2 que intentan que varios usuarios compartan una sola UTXO pueden considerarse como algún tipo de grupo de fondos multiusuario, con los usuarios en posesión de algún tipo de derecho de retiro. Potencialmente, también habrá un mecanismo para agregar fondos al grupo (además de crear el grupo con fondos preasignados).

Para que un fondo de piscina sea útil, debe tener algún tipo de 'estado de datos compartidos' asociado: ¿cómo se divide el valor de txout? Si el fondo de la piscina va a evolucionar con el tiempo, ese estado también debe cambiar a medida que se agregan o eliminan fondos de la piscina. Dado que estamos construyendo sobre Bitcoin, agregar o eliminar fondos de la piscina implicará inevitablemente gastar el UTXO que controla la piscina.

Recuerde que el propio sistema de consenso de Bitcoin se basa en la validación de los cambios de estado: las transacciones prueban a través de sus testigos que los cambios al estado del conjunto UTXO son válidos; la prueba de trabajo nos permite llegar a un consenso sobre qué conjunto de transacciones es correcto. Esto significa que los fondos de la piscina también se basarán en la validación de los cambios de estado: estamos demostrando a cada nodo de Bitcoin que se están siguiendo las reglas de la piscina de fondos en cada cambio de estado.

Pero hay otro aspecto clave de las piscinas de fondos L2 sin confianza: cuando el estado de la piscina de fondos cambia, el sistema debe publicar inherentemente suficientes datos para que los usuarios que participan en la piscina de fondos puedan recuperar sus fondos. Si no hemos hecho eso, entonces nuestro sistema no logra proporcionar retiros unilaterales, sin la cooperación de terceros. Muchos esquemas basados en rollup fallan aquí: sufren de fallas de disponibilidad de datos, donde el usuario no puede recuperar sus fondos si los coordinadores de terceros se desconectan, porque no tienen forma de obtener los datos necesarios para construir una transacción válida de recuperación de fondos.

Con estas limitaciones en mente, ¿en qué estructuras de datos se basarán los fondos de los fondos? Inevitablemente, todos son algún tipo de árbol. Específicamente, algún tipo de árbol merkle. Tienen que ser un árbol, porque eso es prácticamente la única estructura de datos escalable en ciencias de la computación; tienen que estar merkelizados, porque esa es básicamente la única forma razonable de comprometer criptográficamente el estado del árbol. Finalmente, las actualizaciones del árbol inevitablemente se publicarán en la cadena de bloques de Bitcoin, porque esa es la única.medio de publicación todos los usuarios de L2 comparten, y el único en el que podemos obligar a los usuarios a publicar para mover monedas. Y porque cualquier implementación del pacto va a necesitar partes del árbol para validar que se están siguiendo las reglas del pacto.

Entonces, con la teoría de alto nivel fuera del camino, ¿cómo se traduce esto realmente en scripts y transacciones de Bitcoin?

Transacciones Individuales Pre-Firmadas

El caso degenerado de un árbol, con exactamente una hoja en él. Aquí el estado de nuestro fondo de reserva puede cambiar de estado, en términos generales, una vez. Por ejemplo, un canal de Lightning estándar cae en esta categoría y, una vez abierto, solo puede cerrarse. Los datos que se publican cuando se cierra un canal es la propia transacción, que es información suficiente para que la contraparte en el canal aprenda el txid a partir de los datos de la cadena de bloques y recupere sus fondos gastándolos.

El único "pacto" requerido aquí es el pacto más básico: la transacción pre-firmada.

Árboles Txout

El siguiente patrón de diseño más complejo que vemos en los fondos de pools es el árbol de txout. Ark es un ejemplo notable. Aquí, el fondo de pool puede dividirse al gastar el UTXO raíz en un árbol de transacciones predefinidas, obligado con convenios simples como transacciones prefirmadas o CTV, dividiendo el valor de ese UTXO en cantidades cada vez más pequeñas hasta que se llegue a los nodos hoja que pueden gastar los propietarios legítimos.

Es importante reconocer que el propósito del árbol de txout es dar a los usuarios opciones sobre cómo recuperar sus fondos, y esas opciones tienen un costo: un árbol de txout siempre será una forma más costosa de dividir un grupo de fondos, devolviéndolos a sus propietarios, que simplemente dividir el UTXO en una sola transacción. Cada capa en el árbol agrega un costo debido a los bytes utilizados en los txouts y txins necesarios para crear esa capa.

Entonces, ¿qué tipo de opciones podría ofrecer un árbol de txout? Una vez más, Ark es un gran ejemplo: no queremos que el canje en cadena de un solo V-UTXO requiera que todos los V-UTXO se pongan en cadena. Al usar un árbol, la redención puede dividir el árbol en partes más pequeñas hasta que el V-UTXO deseado se ponga en cadena.

Al igual que en el caso de la transacción individual prefirmada, la información que se publica son las propias transacciones, que informan a la billetera de otros usuarios cómo gastar sus fondos si es necesario.

La escalabilidad de los árboles de txout tiene interesantes economías de escala. El costo de la primera V-UTXO que se coloca en la cadena, en un fondo con n V-UTXOs, es aproximadamente log2(n) veces más caro que una transacción única, ya que se deben colocar log2(n) niveles de transacciones divididas en la cadena. Sin embargo, una vez que se coloca la primera V-UTXO en la cadena, los V-UTXOs subsiguientes se vuelven más baratos de redimir en la cadena porque alguien más ya ha pagado el costo de hacer que las transacciones intermedias se minen.

Recuerde que el número total de elementos en un árbol binario con

n hojas es 2n. Esto significa que para poner todos los V-UTXO en la cadena, el costo total de hacerlo a través de un árbol de txout sería un pequeño múltiplo del costo total de hacerlo en una sola transacción. ¡Sorprendentemente eficiente!

O tal vez no... Si el tamaño total de los reembolsos del fondo común es lo suficientemente alto, pueden representar una demanda no trivial sobre el espacio de bloque total general. Blockspace es un sistema de oferta y demanda, por lo que en algún momento las tarifas aumentarán debido a la alta demanda. En el extremo, es muy posible crear árboles de txout tan grandes y tan profundos que en realidad redimir cada

V-UTXO en el árbol es imposible.

Una pregunta abierta con árboles de txout es quién paga las tarifas y cómo. Una solución obvia es utilizar salidas de anclaje sin clave en las transacciones hoja y permitir que quien quiera que las transacciones hoja se extraigan pague las tarifas a través de CPFP. En algunos casos de uso, los V-UTXO en sí mismos pueden gastarse inmediatamente después de su creación, sin un retraso CSV, por lo que los V-UTXO en sí mismos podrían gastarse para agregar tarifas a través de CPFP.

La implementación de RBF es compleja debido a los permisos: el lugar obvio para cobrar comisiones por RBF es el valor de V-UTXO. Pero, ¿cómo garantizar que solo el propietario tenga la capacidad de firmar una transacción con una tarifa más alta? En muchas circunstancias, no es obvio cómo hacerlo de una manera más eficiente que una salida de anclaje sin clave. Sin embargo, no hacerlo plantea desafíos graves para los esquemas utilizados por las billeteras de los usuarios finales, que pueden no tener una UTXO para gastar y realizar un CPFP, si los propios V-UTXO no se pueden gastar inmediatamente.

Finalmente, se debe pensar cuidadosamente en los incentivos que existen en los sistemas de árboles de txout, teniendo en cuenta el pago de comisiones. Por ejemplo, en un sistema tipo Ark, si un conjunto de V-UTXOs individualmente cuesta demasiado dinero para que valga la pena llevarlo a V-UTXOs en cadena, un coordinador desobediente podría negarse a permitir que esos V-UTXOs se canjeen fuera de la cadena, y luego obtener ganancias robando el valor de esos V-UTXOs en un solo gasto de UTXO una vez que se alcance el tiempo de espera.

Si ese fuera el caso, se podría argumentar que dicho sistema no cumpliría nuestros criterios para ser una capa 2 para pequeños V-UTXOs.

Esquemas basados en el saldo

La máquina de estados de un árbol txout sigue siendo relativamente simple: o bien el fondo de fondos existe, o bien se gasta, para crear dos o más fondos de fondo más pequeños. En cambio, con convenios más avanzados, podríamos tratar el fondo común como un saldo en evolución, con la capacidad de sumar y restar fondos de ese saldo.

Para hacer esto, necesitamos implementar una máquina de estados no trivial. Pero también necesitamos lo que es esencialmente una base de datos compartida. ¿Por qué? Porque el objetivo aquí es compartir una UTXO entre muchos propietarios diferentes. Finalmente, si realmente vamos a obtener una mejora de escalabilidad, debemos hacerlo de una manera que coloque la menor cantidad posible de esos datos de propiedad en la cadena.

Estos requisitos nos llevan inherentemente a algún tipo de estructura de datos merkelizada similar a un árbol, como un árbol de suma Merkle. Manipular esa estructura de datos requerirá inherentemente algo como OP_CAT, algún tipo de opcode de verificación de prueba de conocimiento nulo o un opcode específico de manipulación de árbol con un propósito específico.

Curiosamente, al igual que en los árboles txout, no se puede mejorar más que el escalado log(n) mientras se mantienen propiedades de seguridad similares. ¿Por qué? Supongamos que tuviéramos un hipotético OP_ZKP que, a través de algunas matemáticas avanzadas, necesitara solo 32 bytes para probar cualquier declaración. Si bien esta prueba zk podría demostrar que la estructura de datos merkelizada se ha manipulado de acuerdo con las reglas del sistema de la capa 2, no proporcionaría los datos necesarios para que el siguiente usuario también realice un cambio de estado. Esto no cumple con nuestro criterio preferido de habilitar retiros incondicionales: como máximo, un usuario podría lograr un retiro incondicional. Pero ningún otro usuario podría hacerlo.

Por el contrario, si las partes modificadas de la estructura de datos merklizada se publican a través de la scriptsig del convenio, por ejemplo, los digestos hermanos en un árbol de Merkle, el siguiente usuario tiene suficientes datos para actualizar su comprensión del estado del sistema y realizar un retiro incondicional ellos mismos.

Una posible forma de evitar este problema es si el convenio requiere una prueba de publicación en un medio de publicación diferente al de la cadena Bitcoin. Sin embargo, las garantías de seguridad serán más débiles de lo que es posible a través de Bitcoin.

Por último, observe cómo se pueden combinar los árboles txout y un enfoque basado en el equilibrio. Si la estructura de datos que se está manipulando es un árbol de txout, los fondos se pueden agregar al árbol de txout gastando la salida y agregando nuevos fondos, con un script de convenio que valida que los fondos se agregaron de hecho al árbol de txout. Del mismo modo, los fondos pueden ser retirados por todos los mecanismos normalmente disponibles para un árbol txout. Advanced Ark es un ejemplo de esta clase de esquema.

Índice de Datos de Fallos

Las L2 logran escalabilidad al agregar un requisito de interactividad en situaciones adversas. En casi todos los casos, esto significa que las partes honestas en el protocolo tienen plazos para que se les minen las transacciones; si no se cumplen los plazos, los fondos pueden ser robados.

La capacidad máxima de bloque en todas las cadenas de bloques descentralizadas (y centralizadas) está limitada por restricciones técnicas. En Bitcoin, el tamaño máximo de bloque es tal que Bitcoin opera esencialmente a capacidad ~100% del tiempo. Dado que la minería de Bitcoin actúa como un sistema de subasta, subastando espacio de bloque al postor más alto, en la práctica esto significa que la tarifa mínima para que una transacción sea minada sube y baja a medida que la demanda aumenta y disminuye.

La tarifa siempre tiene en cuenta la economía de L2 y los modos de falla. Por ejemplo, en Lightning, los HTLC "del tamaño del polvo" que son demasiado pequeños para ser canjeados de manera rentable en la cadena utilizan un modelo de seguridad diferente al de los HTLC más grandes. Si bien el protocolo Lightning aún no implementa esto correctamente, en teoría este umbral debería ser dinámico, basado en las tasas de tarifas a medida que suben y bajan, idealmente hasta el punto en que una parte pueda elegir si existe o no un HTLC en una transacción de compromiso determinada en función de la tasa de tarifas.

Se ha propuesto una variedad de ataques en los que esta situación se activa intencionadamente con rayos, como inundaciones y saqueos²² y el ataque masivo de salida²³. Dado que la capacidad de la cadena de bloques de Bitcoin se comparte en todos los casos de uso, también son posibles los ataques entre diferentes sistemas L2: por ejemplo, desencadenar una salida masiva en Ark para beneficiarse de los canales Lightning.

Las L2 que comparten UTXO entre varios usuarios hacen que estos problemas sean potencialmente peores, ya que la demanda de espacio de bloque en el peor de los casos durante una falla es proporcionalmente mayor. En el momento de escribir este artículo, nunca hemos visto fallos a gran escala en Lightning en los que haya que cerrar un gran número de canales a la vez. Hay un buen argumento de que deberíamos obtener experiencia operativa adicional con Lightning y su escalado de aproximadamente 1 UTXO por usuario, antes de empujar los límites aún más con los esquemas de uso compartido de UTXO.

En segundo lugar, antes de que se adopten ampliamente nuevos esquemas de uso compartido de UTXO, se debe realizar una investigación cuidadosa sobre la rentabilidad potencial de los ataques durante la alta demanda de espacio en bloque. Por ejemplo, en un sistema como Ark donde el ASP puede canjear fondos utilizando mucho menos espacio en bloque que otras partes, puede ser el caso que provocar intencionalmente tasas de tarifas altas y luego apoderarse de fondos que no se pueden retirar unilateralmente de manera rentable sea un fraude rentable, violando nuestras condiciones para un verdadero sistema de Capa 2.

Consenso de limpieza

Hay varias cosas que Satoshi se equivocó en el protocolo inicial de Bitcoin, en particular, los ataques DoS de secuencias de comandos, el ataque timewarp y los problemas con el árbol de Merkle. Anteriormente, se han solucionado varios otros errores de consenso con soft-forks, como el cambio para evaluar nLockTime basado en el tiempo pasado mediano, (intentar) solucionar el problema de txid duplicado, etc.

El soft-fork más reciente, taproot, tuvo un proceso de implementación relativamente conflictivo, tardando bastante tiempo en ser implementado. Un argumento para hacer primero un soft-fork de limpieza de consenso, antes de habilitar cualquier nuevo opcode u otras características para nuevos tipos de Capa 2, es que aprenderíamos más sobre cuán dispuesta está la comunidad en general a implementar lo que debería ser un soft-fork relativamente no controvertido que beneficia a todos.

Pruebas de L2 dependientes de Soft-Fork

Los desarrolladores no necesitan esperar a que se produzca un soft-fork para probar sus ideas. Los desarrolladores de Ark están utilizando un enfoque particularmente sofisticado en Capa 2.Arca sin pactoes simular los convenios que necesitan con transacciones pre-firmadas. Esto les permite probar las ideas de Ark con BTC real, en mainnet, con las mismas características de confianza que se espera que Ark logre con los convenios. El compromiso es que Ark sin convenios requiere que todas las partes estén en línea para firmar las transacciones pre-firmadas. Dado que clArk funciona con BTC real, puede resultar lo suficientemente útil como para usarlo en producción para ciertos casos de uso que puedan tolerar el compromiso de interactividad.

Un enfoque más simple es simplemente fingir que ciertas partes no pueden hacer las acciones que los convenios impedirían. Por ejemplo, si un protocolo propuesto quiere usar CTV para hacer cumplir que un árbol de txout se gaste en un árbol de transacciones, cada uso de CTV podría reemplazarse con un NOP o CheckSig. Si bien en realidad el árbol txout no se está aplicando, cada bit de código que interactúa con el árbol y cada parte se puede probar como si lo estuviera, y dado que NOP y CheckSig están permitidos en scripts estándar, el protocolo se puede probar en la red principal con fondos reales.

Posibles bifurcaciones suaves

¿Cuál es el camino a seguir? Aquí vamos a trazar todos los esquemas principales de Capa 2 que hemos analizado, y qué bifurcaciones suaves son útiles (U) o necesarias (R) para que estos esquemas de Capa 2 tengan éxito. Como se discutió anteriormente, OP_CAT (y por extensión, Script Revival, que incluye OP_CAT), puede emular todas las otras bifurcaciones suaves en esta lista, con la excepción de OP_Expire y Fee Sponsorship, por lo que no incluiremos OP_CAT donde las necesidades de un proyecto se satisfagan de manera más eficiente por alguna otra bifurcación suave directamente.

También vamos a dejar de lado todos los códigos de manipulación de árboles de merkle propuestos. Todos son demasiado específicos y de nicho para tener una posibilidad significativa de ser adoptados en este momento. En la medida en que estos códigos sean útiles, implementar sus efectos a través de OP_CAT y/o Script Revival es un camino mucho más probable para la adopción.

CTV es el claro ganador aquí, seguido por SIGHASH_ANYPREVOUT (OP_Expire es útil para muchas cosas al ser una solución de ciclos de reemplazo, pero no es esencial). CTV gana porque muchas cosas encajan en el patrón de diseño de "asegurarse de que la transacción de gasto coincida con esta plantilla"; incluso las construcciones OP_CAT pueden hacer un uso eficiente de CTV.

A diferencia de OP_CAT, CTV no parece plantear mucho riesgo de consecuencias no deseadas más allá de fomentar los pagos de comisiones fuera de banda en ciertos casos. Esto no es ideal. Pero nadie ha propuesto una alternativa ampliamente respaldada.

Mi recomendación personal: hacer una limpieza de consenso mediante un soft-fork, seguido de CTV.

Renuncia:

1. Este artículo es una reimpresión de [petertodd], Reenviar el título original '¿Está el plan de desarrollo de Ethereum desviado?', Todos los derechos de autor pertenecen al autor original [petertodd]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Aprender equipo, y lo manejarán con prontitud.

2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.

3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.