Prefacio

La emisión de activos basados en BTC siempre ha sido un tema candente. Desde las primeras Colored Coins en 2011 hasta el recientemente popular protocolo Ordinal, la comunidad BTC siempre ha podido generar nuevos jugadores y consenso, pero pocos se han mantenido. Sin embargo, Lightning Labs ha revelado planes ambiciosos para desarrollar monedas estables basadas en Taproot Assets. Tether también anunció que utilizaría el protocolo RGB para acuñar USDT en la capa 1 de Bitcoin.

Esto significa que el alguna vez famoso OmniLayer (anteriormente Mastercoin) ya no es el actor más importante en el ecosistema BTC. Y los protocolos de activos de validación del lado del cliente (CSV) están comenzando a entrar en la visión de todos. Estos protocolos no sólo mantienen la integridad de los protocolos tradicionales de activos de Bitcoin sino que también mejoran la escalabilidad. Sin embargo, una variedad de protocolos de activos dentro del ecosistema de Bitcoin plantea preguntas pertinentes: ¿en qué se diferencian entre sí y cómo se deben navegar y aprovechar las oportunidades dentro de este panorama?

Este artículo tiene como objetivo guiar a los lectores a través de una revisión exhaustiva de los diversos protocolos de activos que han surgido en la historia de Bitcoin. Además, busca profundizar en las trayectorias potenciales para la evolución de los protocolos de activos basados en Bitcoin en el futuro previsible.

Monedas de colores

El concepto de Colored Coins fue articulado por primera vez por Yoni Assia, ahora director ejecutivo de eToro, en su artículo fundamental “bitcoin 2.X (también conocido como Colored bitcoin)” del 27 de marzo de 2012. El artículo postulaba que la tecnología subyacente de Bitcoin era tan fundamental e impecable como lo es HTTP para Internet. Por lo tanto, el protocolo del token Coloured Coins se diseñó sobre BTC.

Yoni Assia imaginó la creación de economías BTC 2.0 a través de esta innovación, permitiendo a cualquier comunidad generar múltiples monedas de esta manera. Utilizar la tecnología subyacente de Bitcoin para la liquidación de transacciones y la prevención del doble gasto era, en ese momento, una idea pionera.

Coloured Coins es un protocolo diseñado para emitir activos en la cadena de bloques de Bitcoin. Opera “coloreando” una fracción específica de bitcoins para indicar otros activos. Estos Bitcoins marcados aún conservan su funcionalidad original, pero también representan otro activo o valor. La pregunta apremiante, sin embargo, era cómo podría materializarse esta idea en la red Bitcoin.

El 3 de julio de 2014, ChromaWay dio un paso significativo al desarrollar el Protocolo mejorado basado en pedidos de monedas de colores (EPOBC), que simplificó enormemente el proceso de creación de monedas de colores para los desarrolladores. Este fue el protocolo inaugural en emplear la función OP_RETURN de Bitcoin Script.

El resultado fue este:

Esta implementación es muy concisa, pero también trae muchos problemas:

1. Fungibilidad y emisión de valor mínimo vinculante Al vincular 1000 sats en la transacción de génesis para una moneda de color, la unidad mínima de esa moneda de color se convierte en 1 sat. Esto significa que, en teoría, el activo o token se puede dividir en un máximo de 1000 unidades (pero en la práctica es menor para evitar ataques de polvo). Por ejemplo, el valor mínimo de satoshi alguna vez se estableció en 546 SAT, y para los ordinales, es incluso mayor).
2. Desafíos de validación Para determinar la autenticidad y propiedad de una moneda de color, es necesario rastrear y validar su historial de transacciones desde la transacción de génesis hasta el UTXO actual. Por lo tanto, es necesario desarrollar carteras dedicadas, nodos completos e incluso escáneres.
3. Riesgo potencial de censura de mineros ColoredTransaction tiene características distintas, como escribir metadatos en la salida, lo que genera la posibilidad de censura de mineros.

Las Colored Coins son esencialmente un sistema de seguimiento de activos que utiliza las reglas de validación de Bitcoin para rastrear las transferencias de activos. Sin embargo, para demostrar que cualquier salida específica (txout) representa un activo en particular, debe proporcionar la cadena completa de transferencias desde el origen del activo. Esto significa que validar la validez de una transacción puede requerir una larga cadena de pruebas. Para abordar esto, se hicieron propuestas como OP_CHECKCOLORVERIFY para ayudar a validar las transacciones de Colored Coin directamente en BTC, pero la propuesta no fue adoptada.

La primera ICO en criptografía: Mastercoin

El concepto de Mastercoin fue propuesto inicialmente por JR Willett. En 2012, publicó un documento técnico titulado "El segundo documento técnico de Bitcoin ", que describía la idea de crear nuevos activos o tokens sobre la cadena de bloques de Bitcoin existente. Este concepto finalmente llegó a ser conocido como "MasterCoin", que luego pasó a llamarse Omni Layer.

En 2013, el proyecto Mastercoin llevó a cabo una versión inicial de lo que hoy llamamos ICO (Oferta Inicial de Monedas), recaudando con éxito millones de dólares. Esta se considera la primera ICO de la historia. Una de las aplicaciones más notables de Mastercoin es Tether (USDT), una conocida moneda estable con garantía fiduciaria, que se emitió inicialmente en Omni Layer.

De hecho, la idea de Mastercoin es anterior a las monedas de colores. La razón por la que lo estamos discutiendo en segundo lugar es que, en comparación con Coloured Coins, MasterCoin es una solución relativamente más completa. MasterCoin estableció una capa de nodos completos que ofrece funcionalidades más complejas, como contratos inteligentes. Por el contrario, Coloured Coins es más simple y directo, y se centra principalmente en "colorear" o marcar los UTXO de Bitcoin para representar otros activos.

La diferencia clave entre los dos es que en blockchain, Mastercoin solo registra varios tipos de comportamientos de transacciones y no almacena información de activos relacionados. En los nodos de Mastercoin, se mantiene una base de datos del modelo estatal escaneando bloques de Bitcoin, y esta base de datos reside en los nodos fuera de la cadena de bloques.

En comparación con las monedas de colores, Mastercoin puede ejecutar una lógica más compleja. Además, debido a que no registra ni verifica los estados en la cadena de bloques, sus transacciones no necesitan ser consecutivas (coloreadas continuamente).

Sin embargo, para implementar la lógica compleja de Mastercoin, los usuarios deben confiar en el estado mantenido en la base de datos fuera de la cadena dentro de los nodos o ejecutar sus propios nodos Omni Layer para realizar verificaciones.

En resumen:

La principal diferencia entre Mastercoin y Coloured Coins es que Mastercoin no mantiene todos los datos necesarios para el protocolo en la cadena de bloques. En cambio, se apoya en el sistema de consenso de Bitcoin para gestionar su propia publicación y pedido de transacciones, y luego mantiene el estado en una base de datos fuera de la cadena.

Según la información proporcionada por OmniBolt: Omni Layer está proponiendo un nuevo protocolo de activos UBA (activo basado en UTXO) a Tether, que utilizará la actualización Taproot. Este protocolo incorporará información de activos en tapleaf, permitiendo funciones como pagos condicionales. Al mismo tiempo, OmniBolt está trabajando para integrar Stark en la infraestructura Lightning Network de Omni Layer.

El concepto de validación del lado del cliente

Si queremos entender el concepto de Client Side Validation (CSV), debemos remontarnos al año siguiente a la aparición de Coloured Coins y Mastercoin, que es 2013. Ese año, Peter Todd, uno de los primeros investigadores de Bitcoin y criptografía, publicó un artículo titulado "Desenredando la minería de criptomonedas: sellado de tiempo, prueba de publicación y validación".“ Aunque el título no menciona explícitamente la validación del lado del cliente, una lectura cuidadosa revela que este es uno de los primeros escritos en introducir el concepto.

Peter Todd ha estado buscando formas de hacer que el funcionamiento de Bitcoin sea más eficiente. Desarrolló un concepto más complejo de validación del lado del cliente basado en la idea de marcas de tiempo. Además, introdujo el concepto de “sello de un solo uso”, que se mencionará más adelante.

Para seguir el pensamiento de Peter Todd, primero debemos comprender qué problema realmente resuelve Bitcoin. Según Peter Todd, Bitcoin aborda tres cuestiones:

1. Prueba de publicación: la esencia de la prueba de publicación es resolver el problema del doble gasto. Por ejemplo, si Alice quiere transferir algunos bitcoins a Bob, aunque haya firmado una transacción para transferirla a Bob, es posible que Bob no sepa físicamente que dicha transacción existe. Por lo tanto, necesitamos un lugar público para publicar transacciones y todos puedan consultarlas desde allí.
2. Consenso de orden: En los sistemas informáticos, el tiempo físico que habitualmente experimentamos no existe. En los sistemas distribuidos, el tiempo suele ser marcas de tiempo Lamport, que no proporcionan una medida de nuestro tiempo físico sino que ordenan nuestras transacciones.
3. Validación (opcional): la validación en Bitcoin implica verificar las firmas y los montos transferidos en las transacciones BTC. Sin embargo, Peter Todd cree que esta validación no es necesaria para construir un sistema de tokens sobre Bitcoin; es solo una opción de optimización.

En este punto, quizás recuerdes OmniLayer, que comentamos anteriormente. OmniLayer en sí no delega el cálculo y la validación del estado a Bitcoin, pero sí reutiliza la seguridad de Bitcoin. Coloured Coins, por otro lado, confía el seguimiento del estado a Bitcoin. La existencia de estos dos sistemas ya ha demostrado que la validación no necesariamente tiene que ocurrir en la cadena de bloques.

Entonces, ¿cómo verifica efectivamente las transacciones la validación del lado del cliente?

Primero, veamos lo que debe verificarse:

1. Estado (verificación de la lógica de transacción)
2. Verifique que las entradas (TxIn) sean válidas para evitar el doble gasto.

Es fácil notar que para los activos emitidos en Bitcoin, cada transacción requiere la verificación de todo el historial de transacciones relevantes para garantizar que las entradas a las que se hace referencia no se hayan gastado y que el estado sea correcto. Esto es muy poco práctico. Entonces, ¿cómo podemos mejorar esto?

Peter Todd sugiere que podemos simplificar este proceso cambiando el enfoque de la verificación. En lugar de confirmar que la producción no se ha gastado dos veces, este método se centra en garantizar que las entradas de una transacción se hayan publicado y no entren en conflicto con otras entradas. Al ordenar las entradas en cada bloque y utilizar un árbol Merkle, este tipo de verificación se puede realizar de manera más eficiente porque solo requiere una pequeña porción de datos cada vez, no todo el historial de la cadena de la entrada.

La estructura del árbol de compromiso propuesta por Peter Todd es la siguiente:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

Pero, ¿cómo podemos almacenar ese árbol de compromiso en la cadena de bloques? Aquí es donde podemos introducir el concepto de “sello de un solo uso”.

Sello de un solo uso

El sello de un solo uso es uno de los conceptos centrales para comprender CSV. Es similar al sello físico de un solo uso que se utiliza para proteger los contenedores de carga. Un sello de un solo uso es un objeto único que se puede cerrar exactamente una vez en un mensaje. En términos simples, un sello de un solo uso es un mecanismo abstracto que se utiliza para evitar el doble gasto.

Para SealProtocol, hay tres elementos y dos acciones.

Elementos basicos:

1. l: sello
2. m: mensaje, que es la información o transacción
3. w: testigo, alguien o algo que puede verificar el sello

Operaciones básicas: Hay dos acciones básicas:

1. Close(l, m) → w: cierra el sello l en el mensaje m, generando un testigo w.
2. Verify(l, w, m) → bool: Verifica si el sello l se ha cerrado en el mensaje m.

La seguridad de la implementación de un sello de un solo uso significa que un atacante no puede encontrar dos mensajes diferentes m1 y m2 de modo que la función Verificar devuelva verdadero para el mismo sello.

En términos simples, un sello de uso único garantiza que un determinado activo o dato solo se use o bloquee una vez. En el contexto de Bitcoin, esto normalmente significa que un UTXO sólo se puede gastar una vez. Por lo tanto, los resultados de las transacciones de Bitcoin pueden verse como sellos de un solo uso, y cuando un resultado se utiliza como entrada en otra transacción, ese sello se "roto" o "se usa".

Para los activos en Bitcoin, el propio Bitcoin actúa como "testigo" (w) del sello de un solo uso. Esto se debe a que para verificar una transacción de Bitcoin, los nodos deben verificar que cada entrada de la transacción haga referencia a una UTXO válida y no gastada. Si una transacción intenta gastar dos veces un UTXO que ya se ha utilizado, las reglas de consenso de Bitcoin y la red de nodos honestos rechazarán esa transacción.

Para decirlo aún más simple:

Un sello de un solo uso trata cualquier cadena de bloques como una base de datos, donde almacenamos un compromiso con un determinado mensaje y mantenemos su estado como gastado o no gastado.

Resumiendo lo anterior, los activos que utilizan la validación del lado del cliente tienen las siguientes características:

1. Almacenamiento de datos fuera de la cadena: el historial de transacciones, la propiedad y otros datos relevantes de los activos que utilizan la validación del lado del cliente se almacenan principalmente fuera de la cadena. Esto reduce en gran medida la necesidad de almacenamiento de datos en cadena y ayuda a mejorar la privacidad.
2. Mecanismo de compromiso: aunque los datos de los activos se almacenan fuera de la cadena, los cambios o transferencias de estos datos se registran en la cadena a través de compromisos. Estos compromisos permiten que las transacciones dentro de la cadena hagan referencia a estados fuera de la cadena, lo que garantiza la integridad y la inmutabilidad de los datos fuera de la cadena.
3. Testigos en cadena (no necesariamente BTC): aunque la mayoría de los datos y la validación se producen fuera de la cadena, los activos que utilizan la validación del lado del cliente aún pueden aprovechar la seguridad de la cadena de bloques subyacente (prueba de publicación, orden de transacciones) a través de compromisos integrados en -cadena.
4. Trabajo de validación realizado en el lado del cliente: la mayor parte del trabajo de validación se realiza en el dispositivo del usuario. Esto significa que no todos los nodos de la red necesitan participar en la validación de cada transacción; sólo las partes involucradas deben verificar la validez de la transacción.

Para aquellos que usan activos con validación del lado del cliente, hay un punto adicional a tener en cuenta:

Al realizar transacciones y validar activos con validación del lado del cliente fuera de la cadena, es necesario no solo presentar la clave privada que contiene el activo, sino también proporcionar una prueba completa de la ruta Merkle para el activo correspondiente.

RGB, el pionero de CSV

El concepto de RGB fue propuesto por Giacomo Zucco, una figura muy conocida en la comunidad, después de 2015. Este fue un período en el que Ethereum estaba en auge, las ICO (ofertas iniciales de monedas) proliferaban y se hicieron muchos intentos de crear proyectos más allá de Bitcoin, como Mastercoin y Coloured Coins.

Giacomo Zucco se mostró decepcionado con estos acontecimientos. Creía que ninguno de estos proyectos igualaba el potencial de Bitcoin y que los intentos anteriores de implementar tokens en Bitcoin eran inadecuados. Durante este tiempo, conoció a Peter Todd y quedó fascinado con sus ideas sobre la validación del lado del cliente (CSV). Esto le llevó a proponer la idea de RGB.

Además de las características mencionadas anteriormente de los activos que utilizan la validación del lado del cliente, la principal diferencia con RGB y los protocolos de activos anteriores es la adición de una VM (máquina virtual) de ejecución para la ejecución completa del contrato de Turing. Para garantizar la seguridad de los datos del contrato, se diseñaron el esquema y la interfaz. El esquema, similar al de Ethereum, declara el contenido y las funciones de un contrato, mientras que la interfaz es responsable de la implementación de funciones específicas, similares a las interfaces en los lenguajes de programación.

Los esquemas de estos contratos son responsables de restringir comportamientos que superen las expectativas durante la ejecución de la VM. Por ejemplo, RGB20 y RGB21 son respectivamente responsables de imponer ciertas restricciones a los tokens fungibles y no fungibles durante las transacciones.

El mecanismo de compromiso utilizado en RGB, Pedersen Hash

Su ventaja radica en su capacidad de comprometerse con un valor sin revelarlo. Usar Pedersen Hash para construir un árbol Merkle significa que puede crear un árbol Merkle que proteja la privacidad y que pueda ocultar sus valores. Esta estructura es útil en ciertos protocolos que preservan la privacidad, como algunos proyectos de criptomonedas anónimos. Sin embargo, puede que no sea adecuado para activos CSV, que se mencionarán más adelante en comparación con Taproot Assets.

Diseño de máquinas virtuales para simplicidad RGB → AluVM

RGB tenía como objetivo no solo implementar un protocolo de activos validado del lado del cliente, sino también extender la ejecución completa de máquinas virtuales y la programación de contratos de Turing. Inicialmente, RGB afirmó utilizar un lenguaje de programación llamado Simplicity, que genera una prueba de ejecución y permite la verificación formal (para evitar errores) de los contratos escritos en él. Sin embargo, el desarrollo de este lenguaje no salió según lo planeado, lo que generó complicaciones que finalmente obstaculizaron todo el protocolo RGB. Finalmente, RGB comenzó a utilizar una VM llamada AluVM, desarrollada por Maxim, con el objetivo de evitar cualquier comportamiento indefinido, similar al Simplicity original. Se dice que el nuevo AluVM será reemplazado en el futuro por un lenguaje de programación llamado Contractum, alejándose del uso actual de Rust.

Dirección de escalado RGB Layer2: ¿Red Lightning o Sidechain?

Los activos validados del lado del cliente no pueden negociarse continuamente de forma segura fuera de la cadena porque aún dependen de L1 para la publicación y el pedido de transacciones. Esto significa que sin una solución de escalado de capa 2, su velocidad de transacción aún está limitada por la velocidad de producción de bloques de su testigo L1. Esto implica que si las transacciones RGB se realizan directamente en Bitcoin, bajo estrictos requisitos de seguridad, el tiempo entre dos transacciones relacionadas debería ser de al menos diez minutos (el tiempo de bloqueo de BTC), lo que a menudo es inaceptablemente lento.

RGB y la red Lightning

En términos simples, Lightning Network opera haciendo que las partes de una transacción firmen un conjunto de contratos (transacciones de compromiso) fuera de la cadena. Estos contratos garantizan que si alguna de las partes viola el acuerdo, la parte agraviada puede enviar el contrato (transacción de compromiso) a BTC para su liquidación, recuperar sus fondos y penalizar al infractor. En otras palabras, Lightning Network garantiza la seguridad de las transacciones fuera de la cadena a través de un protocolo y un diseño de teoría de juegos.

RGB podría construir su propia infraestructura Lightning Network diseñando detalles del contrato de canal de pago adecuados para el propio RGB. Sin embargo, construir una infraestructura de este tipo no es fácil debido a la alta complejidad de Lightning Network, especialmente considerando los años de trabajo de Lightning Labs en este campo y la participación de mercado de LND de más del 90%.

Cadena lateral Prime de RGB

LNP-BP, el actual mantenedor del protocolo RGB, publicó una propuesta en junio de 2023 de Maxim para una solución de escalado de activos validada por el lado del cliente llamada Prime. En él, Maxim criticó las soluciones de escalamiento de cadena lateral y Lightning Network existentes por ser demasiado complejas en su desarrollo. Expresó su creencia de que, además de Prime, los otros métodos de expansión, incluidos los canales Lightning de múltiples nodos de NUCLEUS y las fábricas de canales Ark/Enigma, requerirían más de dos años de desarrollo. Sin embargo, Prime podría completarse en sólo un año.

Prime no está diseñado como una cadena de bloques tradicional. En cambio, es una capa modular de publicación de pruebas creada específicamente para la validación del lado del cliente. Consta de cuatro componentes principales:

1. Servicio de marca de tiempo: este servicio puede finalizar una secuencia de transacciones en tan solo 10 segundos.
2. Pruebas: se almacenan en forma de árboles parciales de Merkle (PMT) y se producen y publican junto con los encabezados de los bloques.
3. Sellos de un solo uso: Este es un protocolo abstracto de sellos de un solo uso diseñado para evitar el doble gasto. Cuando se implementa en Bitcoin, se puede vincular a UTXO, similar al diseño RGB actual.
4. Protocolo de contrato inteligente: contratos fragmentados para RGB (que pueden reemplazarse)

A partir de esto, podemos ver que para abordar el problema de los tiempos de confirmación de transacciones en RGB, Prime utiliza un servicio de marca de tiempo para confirmar rápidamente las transacciones fuera de la cadena y empaquetarlas con ID en bloques. Al mismo tiempo, las pruebas de transacciones en Prime se pueden consolidar aún más a través de PMT y luego anclarse en BTC en forma de punto de control.

Protocolo de activos CSV basado en Taproot: Taproot Assets

Taproot Assets es un protocolo de activos CSV basado en Taproot, diseñado para emitir activos en la cadena de bloques de Bitcoin. Estos activos se pueden negociar instantáneamente, en grandes volúmenes y a bajo costo a través de Lightning Network. El núcleo de Taproot Assets es la utilización de la seguridad y estabilidad de Bitcoin junto con la velocidad, escalabilidad y bajo costo de Lightning Network. El protocolo fue diseñado y desarrollado por roasbeef, el CTO de Lightning Labs. Roasbeef es probablemente la única persona en el planeta que ha liderado personalmente el desarrollo de un cliente Bitcoin (BTCD) y un cliente Lightning Network (LND), demostrando un profundo conocimiento de BTC.

Las transacciones Taproot solo llevan el hash raíz del script de activos, lo que dificulta que los observadores externos identifiquen si involucran Taproot Assets, porque el hash en sí es genérico y puede representar cualquier dato. Con la actualización de Taproot, Bitcoin ganó la capacidad de ejecutar contratos inteligentes (TapScript). Sobre esta base, la codificación de activos de Taproot Assets esencialmente crea una definición de token similar a ERC20 o ERC721. Por lo tanto, Bitcoin no solo adquiere la capacidad de definir activos, sino que también adquiere la capacidad de redactar contratos inteligentes, sentando las bases para una infraestructura de contrato inteligente simbólica para Bitcoin.

La estructura de codificación de Taproot Assets es la siguiente:

por roasbeef, CTO de Lighting Labs

Además, como protocolo de activos CSV, Taproot Assets tiene un diseño más conciso en comparación con RGB. La mayor diferencia entre Taproot Assets y RGB en términos de escalabilidad de la aplicación radica en la VM de ejecución, Taproot Assets utiliza la misma VM TaprootScript que la predeterminada nativa de BTC. En los últimos años, muchas de las investigaciones sobre la infraestructura de BTC se han basado en TapScript, pero debido a la lenta actualización de BTC, no se puede aplicar en un corto período de tiempo, por lo que Se puede predecir que Taproot Assets será un campo de pruebas para estas nuevas ideas en el futuro.

Diferencias entre activos Taproot y RGB

1. Validación de transacciones y compatibilidad con los nodos ligeros

Taproot Assets, debido a la implementación de un árbol de suma, tiene una alta eficiencia y seguridad de verificación. Permite que la verificación estatal y las transacciones se realicen simplemente poseyendo una prueba, sin la necesidad de recorrer todo el historial de transacciones. En contraste, el uso por parte de RGB de los compromisos de Pedersen dificulta la verificación efectiva de la validez de los insumos. Como resultado, RGB requiere rastrear el historial de transacciones de los insumos, lo que puede convertirse en una carga significativa a medida que las transacciones se acumulan con el tiempo. El diseño del árbol de suma de Merkel también permite a Taproot Assets facilitar fácilmente la verificación de nodos ligeros, una característica que anteriormente no estaba disponible en los protocolos de activos creados sobre Bitcoin.

2. Máquina virtual de ejecución

Taproot Assets se desarrolló en respuesta a la actualización de Taproot de la red Bitcoin. Utiliza TaprootScriptVM, que es el motor de ejecución de scripts que viene con Bitcoin luego de la actualización de Taproot. Además, utiliza vPSBT, una variante del PSBT de Bitcoin, lo que indica que una vez que se desarrolle el mecanismo del canal Lightning de Taproot Assets, podrá reutilizar inmediatamente toda la infraestructura actual de LND (Lightning Network Daemon), así como productos anteriores de Lightning Labs (LND). actualmente posee más del 90% de la cuota de mercado en la red de rayos). Además, la reciente y popular propuesta de BitVM se basa en TaprootScript, lo que teóricamente significa que todas estas mejoras podrían eventualmente beneficiar a Taproot Assets.

Sin embargo, RGB funciona de manera algo diferente. Su máquina virtual y sus reglas de validación (SCHEMA) son parte de un sistema autónomo, formando un ecosistema algo cerrado. RGB opera dentro de su propio ecosistema y su relación con el ecosistema Bitcoin más amplio no es tan estrecha como algunos podrían pensar. Por ejemplo, con respecto a la actualización de Taproot, la única interacción real de RGB es codificar datos de compromiso en la cadena de bloques en Witness TapLeaf. Esto ilustra que RGB y la actualización Taproot están mínimamente conectados.

3. Contratos inteligentes

En la implementación actual de RGB, se hace mucho hincapié en los contratos y la VM. Sin embargo, en Taproot Assets, no parece haber un enfoque en los contratos inteligentes, al menos no todavía. La implementación RGB actual aún no ha explicado cómo las modificaciones al Estado Global se sincronizan con los fragmentos de contrato individuales (UTXO). Además, si bien los compromisos de Pedersen pueden garantizar la cantidad total de activos, no está claro cómo se protegerían otros estados contra la manipulación, ya que no ha habido muchas explicaciones al respecto.

Por otro lado, Taproot Assets tiene un diseño más simple, pero actualmente solo almacena saldos de activos y no maneja estados más complejos, lo que hace que las discusiones sobre contratos inteligentes sean prematuras. Sin embargo, según Lightning Labs, hay planes para centrarse en el diseño de contratos inteligentes para Taproot Assets el próximo año.

4. Centro de sincronización

El principio básico mencionado anteriormente con respecto a los activos que se verifican en el lado del cliente indica que tener la Prueba es tan importante como tener la clave privada. Sin embargo, existe el riesgo de perder la Prueba ya que se guarda en el lado del cliente. ¿Cómo se puede abordar esto? En Taproot Assets, este problema se puede evitar mediante el uso de un "universo". Un universo es un árbol Merkle disperso públicamente auditable que cubre uno o más activos. A diferencia de un árbol de activos Taproot estándar, no se utiliza un universo para custodiar los activos Taproot. En cambio, se compromete con un subconjunto de uno o más historiales de activos.

En el sistema RGB, Storm cumple esta función, que sincroniza datos de prueba fuera de la cadena a través de una red peer-to-peer (p2p). Sin embargo, debido a razones históricas asociadas con el equipo de desarrollo de RGB, estos equipos actualmente utilizan formatos de prueba incompatibles. El equipo del ecosistema RGB, DIBA, ha indicado que desarrollará “carbonado” para abordar este problema, pero sus avances no están claros.

5. Implementación de ingeniería

Todas las bibliotecas utilizadas por Taproot Assets están bien probadas, ya que Lightning Labs tiene su propio cliente Bitcoin (BTCD), cliente Lightning Network (LND) y una amplia gama de implementaciones de bibliotecas de billetera. Por el contrario, la mayoría de las bibliotecas utilizadas para la implementación RGB son autodefinidas. Desde la perspectiva de los estándares de la industria, la implementación de RGB aún se encuentra en la etapa experimental.

Una breve mirada al futuro del escalado de BTC

Continuando con la discusión, se hace evidente que los protocolos de activos validados por el cliente han ido más allá del alcance de los protocolos tradicionales y ahora se dirigen hacia la escalabilidad computacional.

Mucha gente afirma que en el futuro Bitcoin existirá como "oro digital", mientras que otras cadenas de bloques crearán ecosistemas de aplicaciones. Sin embargo, tengo una opinión diferente. Como se ve en muchas discusiones en foros de Bitcoin, se habla mucho sobre varias monedas alternativas y su fugaz vida útil. La rápida desaparición de estas monedas alternativas ha convertido el capital y el esfuerzo que las rodea en burbujas. Ya tenemos a Bitcoin como una base sólida de consenso; no es necesario crear nuevas soluciones de Capa 1 (L1) solo para protocolos de aplicación. Lo que deberíamos hacer es aprovechar Bitcoin, esta sólida infraestructura, para construir un mundo descentralizado a más largo plazo.

Menos cálculo en cadena, más verificación en cadena

Desde la perspectiva del diseño de aplicaciones, Bitcoin eligió desde el principio una filosofía centrada no en el cálculo en cadena sino en la verificación (integridad y estado de Turing para contratos inteligentes). La esencia de una blockchain es una máquina de estados replicada. Si el consenso de una cadena de bloques se centra en el cálculo dentro de la cadena, es difícil argumentar que hacer que cada nodo de la red repita estos cálculos sea un enfoque razonable o escalable. Si la atención se centra en la verificación, entonces validar las transacciones fuera de la cadena podría ser el enfoque más adecuado para la escalabilidad de Bitcoin.

¿Dónde se realiza la verificación? Esto es crucial.

Para los desarrolladores que crean protocolos sobre Bitcoin, cómo utilizar Bitcoin para la verificación crítica, o incluso colocar la verificación fuera de la cadena, y cómo diseñar esquemas seguros, son cuestiones que corresponden a los propios diseñadores de protocolos. No deberían ni necesitan estar asociados con la cadena misma. La forma de implementar la verificación conducirá a diferentes soluciones de escalamiento para BTC.

Desde la perspectiva de las implementaciones basadas en verificación, tenemos tres direcciones para escalar:

1.Verificación en cadena (OP-ZKP)

La implementación de OP-ZKP directamente en TaprootScriptVM dotaría al propio Bitcoin de la capacidad de realizar la verificación ZKP. Esto, junto con algunos protocolos de liquidación de diseño de Covenant, podría crear una solución de escalamiento Zk-Rollup que herede la seguridad de Bitcoin. Sin embargo, a diferencia de implementar un contrato de verificación en Ethereum, las actualizaciones de Bitcoin son inherentemente lentas, y agregar un código de operación tan especializado y potencialmente necesario para una actualización seguramente será un desafío.

2.Verificación en semi-on-chain (BitVM)

El diseño de BitVM garantiza que no esté destinado a la lógica de transacciones ordinaria. Robin Linus también ha indicado que el futuro de BitVM radica en la creación de un mercado libre entre cadenas para varias SideChains. El enfoque de BitVM se considera semi-en cadena porque la mayoría de los cálculos de verificación no ocurrirán dentro de la cadena sino fuera de la cadena. La razón importante para diseñar en torno a Taproot de Bitcoin es utilizar TapScriptVM para la verificación computacional cuando sea necesario, heredando teóricamente la seguridad de Bitcoin. Este proceso también genera una cadena de confianza de verificación, como la necesidad de solo un verificador honesto entre 'n' verificadores, lo que se conoce como Optimistic Rollups.

BitVM incurre en una importante sobrecarga en la cadena, pero ¿puede utilizar las pruebas de fraude de ZK para ganar eficiencia? La respuesta es no, ya que la implementación de pruebas de fraude ZK depende de la capacidad de realizar la verificación ZKP en cadena, lo que nos lleva nuevamente a las dificultades del enfoque OP-ZKP.

3.Verificación fuera de la cadena (validación del lado del cliente, Lightning Network)

La verificación completa fuera de la cadena se refiere a los protocolos de activos CSV discutidos anteriormente y Lightning Network. Como se vio en discusiones anteriores, no podemos evitar por completo la colusión en los diseños CSV. Lo que podemos hacer es utilizar criptografía y diseño de protocolos para mantener el daño causado por la colusión maliciosa dentro de límites controlables, haciendo que tales acciones no sean rentables.

Las ventajas y desventajas de la verificación fuera de la cadena son igualmente claras. La ventaja es que utiliza recursos mínimos en la cadena y tiene un enorme potencial de escalabilidad. La desventaja es que es casi imposible heredar completamente la seguridad de Bitcoin, lo que limita en gran medida los tipos y métodos de transacciones fuera de la cadena que se pueden realizar. Además, la verificación fuera de la cadena también implica que los datos se mantienen fuera de la cadena y son administrados por los propios usuarios, lo que impone mayores exigencias a la seguridad del entorno de ejecución del software y a la estabilidad del software.

Tendencia de evolución de escala

Actualmente, las soluciones populares de Capa 2 en Ethereum, en términos de paradigma, validan los cálculos de la Capa 2 a través de la Capa 1, lo que significa que el cálculo del estado se lleva a la Capa 2, pero la verificación aún se retiene en la Capa 1. En el futuro, podríamos impulsar de manera similar el cálculo de verificación fuera de la cadena, liberando aún más el rendimiento de la infraestructura blockchain actual.

Descargo de responsabilidad:

1. Este artículo se reimprime de [espejo]. Todos los derechos de autor pertenecen al autor original [Ben77]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones 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 están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.