Introducción

La emisión de activos basados en BTC siempre ha sido un tema candente. Desde la primera aparición de Coloured Coins en 2011 hasta el recientemente popular Protocolo Ordinal, la comunidad BTC siempre ha podido generar nuevos jugadores y consenso. Sin embargo, pocos han resistido la prueba del tiempo. Con los ambiciosos Lightling Labs anunciando su plan para construir una moneda estable sobre Taproot Assets, y Tether declarando su elección de RGB para acuñar USDT en la primera capa de Bitcoin, está claro que el alguna vez famoso OmniLayer (Mastercoin) ya no es el más grande. jugador en el ecosistema BTC. Los protocolos de activos de validación del lado del cliente (CSV) están empezando a ganar atención y se diferencian de los protocolos de activos tradicionales de BTC al incorporar también características para la escalabilidad de Bitcoin. Pero ante tal multitud de protocolos de activos en el ecosistema BTC, cabe preguntarse: ¿cuáles son sus diferencias? ¿Y cómo deberíamos elegir y encontrar nuestras propias oportunidades entre estos numerosos protocolos de activos?

Este artículo tiene como objetivo guiar a los lectores en la revisión de varios protocolos de activos que han aparecido en la historia de Bitcoin, profundizando en la trayectoria potencial de los protocolos de activos basados en Bitcoin en el futuro previsible.

Monedas de colores

La idea de las monedas de colores fue propuesta por primera vez por Yoni Assia, el actual director ejecutivo de eToro, en un artículo escrito el 27 de marzo de 2012, titulado "bitcoin 2.X (también conocido como bitcoin de colores)". El artículo postuló que Bitcoin, como tecnología subyacente, es perfecta, al igual que HTTP es la base de Internet. Por lo tanto, sobre la base de la reutilización de BTC, se diseñó el protocolo de token Coloured Coins.

Yoni Assia tenía como objetivo crear una economía BTC 2.0 a través de este método: cualquier comunidad podría crear una variedad de monedas de esta manera. Este enfoque de utilizar Bitcoin como tecnología subyacente para compensar transacciones y evitar el doble gasto fue sin duda una idea muy audaz en ese momento.

Como protocolo para la emisión de activos basados en Bitcoin, el método de Coloured Coins consiste en "colorear" una cierta cantidad de Bitcoin para representar estos activos. Estos Bitcoins marcados funcionalmente siguen siendo Bitcoins, pero también representan otro activo o valor. Pero, ¿cómo podría implementarse esta idea en Bitcoin?

El 3 de julio de 2014, ChromaWay desarrolló un protocolo de monedas de colores (EPOBC) basado en Enhanced Pay-to-Script-Hash (P2SH), que simplificó el proceso para que los desarrolladores crearan monedas de colores. Este fue el primer protocolo en adoptar la funcionalidad OP_RETURN de Bitcoin Script.

La implementación final se muestra en la siguiente imagen:

)

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

Tokens homogeneizados y valor vinculante mínimo

En la transacción de génesis, si una moneda de color está atada con 1000 sats, la unidad dividida más pequeña de esta moneda de color es 1 sat. Esto significa que el activo o token se puede dividir o asignar en un máximo de 1000 partes (pero esto es solo teórico, para evitar ataques de polvo, por ejemplo, el sat solía establecerse en 546 SAT, y luego en ordinal que es mayor ).

Problemas de verificación

Para determinar la autenticidad y propiedad de una moneda de color, es necesario rastrear y verificar desde la transacción de génesis del activo hasta el UTXO actual. Por lo tanto, es esencial desarrollar una billetera dedicada y un nodo completo que la acompañe, e incluso un navegador.

Riesgo potencial de censura minera

Debido a las características distintivas de ColoredTransaction, que implica escribir información de metadatos en la salida, existe la posibilidad de que los mineros censuren.

Las monedas de colores son esencialmente un sistema de seguimiento de activos que utiliza las reglas de verificación de Bitcoin para rastrear las transferencias de activos. Sin embargo, para demostrar que cualquier salida específica (txout) representa un determinado activo, se requiere toda una cadena de transferencia desde el origen del activo hasta el presente. Esto significa que verificar la legitimidad de una transacción puede requerir una larga cadena de pruebas. Para abordar este problema, hubo una propuesta para que OP_CHECKCOLORVERIFY ayudara a verificar directamente la exactitud de las transacciones de Colored Coins en BTC, pero esta propuesta no fue aprobada.

La primera ICO en la industria de las criptomonedas: Mastercoin

El concepto inicial de Mastercoin fue propuesto por JR Willett. En 2012, publicó un documento técnico titulado "El segundo documento técnico de Bitcoin", que describía el concepto de crear nuevos activos o tokens en la cadena de bloques existente de Bitcoin, más tarde conocida como "MasterCoin". Posteriormente pasó a llamarse Omni Layer.

El proyecto Mastercoin llevó a cabo una venta inicial de tokens (lo que hoy llamamos ICO u Oferta Inicial de Monedas) en 2013, recaudando con éxito millones de dólares. Esta se considera la primera ICO de la historia. La aplicación más notable de Mastercoin es Tether (USDT), la moneda estable fiduciaria más conocida, que se emitió inicialmente en Omni Layer.

De hecho, el concepto de Mastercoin es anterior a las monedas de colores. La razón por la que se analiza en segundo lugar aquí es que, en comparación con Coloured Coins, Mastercoin es una solución relativamente más compleja. Mastercoin estableció una capa de nodos completa, ofreciendo así funcionalidades más complejas (como contratos inteligentes), mientras que Coloured Coins era más simple y directo, centrándose principalmente en "colorear" o marcar los UTXO de Bitcoin para representar otros activos.

La diferencia clave con Coloured Coins es que Mastercoin solo publica varios tipos de comportamientos de transacciones en la cadena, sin registrar información de activos relacionada. En los nodos de Mastercoin, se mantiene una base de datos de modelo de estado escaneando bloques de Bitcoin en nodos fuera de la cadena.

En comparación con las monedas de colores, Mastercoin puede ejecutar una lógica más compleja. Y debido a que no registra el estado ni realiza validación en la cadena, sus transacciones no requieren continuidad (coloración continua).

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

En resumen:

La principal diferencia entre Mastercoin y Coloured Coins es que Mastercoin decidió no mantener todos los datos necesarios para el protocolo en cadena. En cambio, utilizó de forma parasitaria el sistema de consenso de BTC para implementar su propia publicación y pedido de transacciones, mientras mantenía 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) para Tether, que utilizará la actualización Taproot para codificar información de activos en tapleaf, permitiendo funcionalidades como pagos condicionales. Mientras tanto, OmniBolt está introduciendo Stark en la infraestructura Lightning Network de OmniLayer.

El concepto de validación del lado del cliente

Para comprender el concepto de validación del lado del cliente, debemos remontarnos al año siguiente al surgimiento de Coloured Coins y Mastercoin, que es 2013. Ese año, Peter Todd publicó un artículo: "Desenredando la minería de criptomonedas: sellado de tiempo, prueba de publicación y validación". Aunque el título del artículo no parece estar directamente relacionado con la validación del lado del cliente, una lectura cuidadosa revela que contiene las primeras ideas esclarecedoras sobre la validación del lado del cliente.

Peter Todd, uno de los primeros investigadores de Bitcoin y criptografía, siempre ha estado buscando un método para 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 el concepto de marcas de tiempo. Además, introdujo el concepto de “sello de un solo uso”, que se mencionará más adelante.

Siguiendo los pensamientos de Peter Todd, primero comprendamos los problemas que realmente resolvió BTC (Bitcoin). En opinión de Peter Todd, BTC resolvió tres problemas:

Prueba de publicación

La esencia de la prueba de publicación es resolver el problema del doble gasto. Por ejemplo, Alice tiene algunos bitcoins que quiere transferirle a Bob. Aunque ella firma una transacción para transferirla a Bob, es posible que Bob no sepa físicamente la existencia de la transacción. Por lo tanto, es necesario que haya un lugar público para publicar transacciones, donde todos puedan consultarlas.

Consenso de pedidos

En los sistemas informáticos el tiempo físico que habitualmente percibimos no existe. En los sistemas distribuidos, el tiempo suele estar representado por marcas de tiempo Lamport, que no miden nuestro tiempo físico sino que ordenan nuestras transacciones.

Validación (opcional)

La validación en BTC se refiere a la verificación de firmas y montos de transferencia de BTC. Sin embargo, en este caso, Peter Todd creía que esta validación no es necesaria para construir un sistema de tokens sobre BTC, sino más bien una opción de optimización.

En este punto, podrías pensar en Ominilayer mencionado anteriormente. Ominilayer en sí no delega el cálculo y la verificación del estado a BTC, pero aún así reutiliza la seguridad de BTC. Coloured Coins, por otro lado, delega el seguimiento del estado a BTC. La existencia de ambos demuestra que la validación no necesariamente tiene que ocurrir en la cadena.

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

Veamos primero lo que hay que validar:

• Estado (validación de lógica de transacción)

• Validez de entrada de TxIn (para evitar el doble gasto)

Es evidente que para los activos emitidos en BTC, cada transacción requiere la verificación de todo el historial de transacciones relacionadas para garantizar que la entrada a la que se hace referencia no se haya gastado y que el estado sea correcto. Esto es altamente ineficiente. Entonces, ¿cómo se puede mejorar?

Peter Todd cree que podemos simplificar este proceso cambiando el enfoque de la validación. En lugar de confirmar que un producto no se ha gastado dos veces, este método se centra en confirmar que los insumos de la transacción se han publicado y no están en conflicto con otros insumos. Al ordenar las entradas en cada bloque y utilizar un árbol Merkle, este tipo de validación se puede realizar de manera más eficiente, ya que cada validación requiere solo una pequeña porción de datos, no todo el historial de la cadena de esa entrada.

Peter Todd propuso la estructura de un árbol de compromiso de la siguiente manera:

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

Pero, ¿cómo almacenamos ese árbol de compromiso en la cadena? Esto nos lleva al concepto de precinto de un solo uso.

Sello de un solo uso

El sello de un solo uso es uno de los conceptos centrales para comprender la validación del lado del cliente, similar a los sellos físicos de un solo uso que se utilizan para proteger los contenedores de carga en el mundo real. Un sello de un solo uso es un objeto único que puede cerrar con precisión un mensaje una vez. En resumen, 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, es decir, sello
2. m: mensaje, mensaje
3. En: testigo, testigo

Operaciones básicas: Hay dos operaciones básicas:

1. Cerrar (l, m) → w: en el sello de cierre de messagemupper, genera un testigoEn。
2. Verify(l,w,m) → bool: Verificar sello¿Estás en las noticias?está cerrado.

La implementación del sello de un solo uso es en términos de seguridad. Un atacante m1 y m2 no pueden encontrar dos mensajes diferentes, lo que hace que la función Verificar devuelva el mismo sello verdadero de.

En primer lugar, el Sello de un solo uso es un concepto que garantiza que un determinado activo o dato solo se utilice o bloquee una vez. En el contexto de Bitcoin, esto generalmente significa que un UTXO (salida de transacción no gastada) solo se puede gastar una vez. Por lo tanto, el resultado de una transacción de Bitcoin puede considerarse un sello de una sola vez, y cuando este resultado se utiliza como insumo para otra transacción, el sello se "rompe" o "se usa".

Para los activos CSV en BTC, el propio Bitcoin actúa como un "testigo" sellado por única vez. Esto se debe a que, para validar una transacción de Bitcoin, un nodo debe verificar que cada entrada a 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 gastado, las reglas de consenso de Bitcoin y los nodos honestos en toda la red rechazarán la transacción.

¿Puede ser más sencillo?

Sello de un solo uso Es decir, cualquier blockchain se considera una base de datos. Almacenamos la promesa de un determinado mensaje en esta base de datos de alguna manera y mantenemos un estado consumido o por consumir.

Sí, es así de simple.

En resumen, los activos verificados por el cliente tienen las siguientes características:

1. Almacenamiento de datos fuera de la cadena: la mayor parte del historial de transacciones, la propiedad y otros datos relacionados de los activos verificados por el cliente se almacenan fuera de la cadena. Esto reduce en gran medida las necesidades 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 a estos datos se registrarán 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, garantizando así la integridad y la no manipulación de los datos fuera de la cadena.
3. Testigo en cadena (no necesariamente BTC): si bien la mayoría de los datos y la verificación se realizan fuera de la cadena, los activos verificados por el cliente aún pueden aprovechar la seguridad de la cadena subyacente (emisión de pruebas, ordenación de transacciones) a través de compromisos integrados en -cadena.
4. La verificación se realiza en el lado del cliente: la mayor parte del trabajo de verificación se realiza en el dispositivo del usuario. Esto significa que no es necesario que todos los nodos de la red participen en la verificación de cada transacción, solo los participantes involucrados deben verificar la validez de la transacción.

Para aquellos que utilizan la verificación de activos del lado del cliente, hay otro punto a tener en cuenta:

Al negociar fuera de la cadena y verificar activos verificados por el cliente, no solo debe mostrar la clave privada que contiene el activo, sino también mostrar prueba de la ruta Merkel completa del activo correspondiente.

El pionero en validación del lado del cliente (CSV): RGB

El concepto de RGB fue propuesto por Giacomo Zucco, una figura muy conocida en la comunidad, después de 2015. Debido al auge de Ethereum y la proliferación de las ICO, y antes de las ICO, muchas personas intentaron hacer cosas fuera de Bitcoin, como los proyectos Mastercoin y Coloured Coins. .

Giacomo Zucco expresó su decepción. Él cree que estos proyectos son inferiores a Bitcoin y cree que las formas anteriores de implementar tokens en Bitcoin son inapropiadas. En el proceso, conoció a Peter Todd y quedó fascinado con la idea de Peter Todd de validación del lado del cliente. Luego empezó a proponer la ideaRGB .

La mayor diferencia entre RGB y los protocolos de activos anteriores es que, además de las características mencionadas anteriormente de verificación de activos del lado del cliente, también agrega una VM de ejecución para implementar un motor de ejecución de contratos completo de Turing. Además, para garantizar la seguridad de los datos del contrato, también se diseñan el esquema y la interfaz. Schema es similar a Ethereum, declara el contenido y las funciones del contrato, mientras que Interface es responsable de la implementación de funciones específicas, al igual que la interfaz en los lenguajes de programación.

Los esquemas de estos contratos son responsables de restringir comportamientos que no exceden el comportamiento esperado cuando se ejecuta la máquina virtual, como RGB20 y RGB21, que son respectivamente responsables de algunas restricciones en las transacciones de tokens fungibles y tokens no fungibles.

Mecanismo de compromiso de RGB: Pedersen Hash

En términos de mecanismos de compromiso, RGB adopta el Pedersen Hash. Su ventaja radica en poder comprometerse con un valor sin revelarlo. Usar Pedersen Hash para construir un árbol Merkle significa que puede crear un árbol Merkle protegido por la privacidad que oculta los valores que contiene. Esta estructura se puede utilizar en ciertos protocolos específicos de protección de la privacidad, como algunos proyectos anónimos de criptomonedas. Sin embargo, puede que no sea adecuado para activos CSV, que se mencionarán más adelante en la comparación con Taproot Assets.

Diseño de máquinas virtuales de RGB: de la simplicidad a AluVM

RGB tiene como objetivo no solo implementar un protocolo de activos validado por el cliente, sino también extender la ejecución completa de máquinas virtuales y la programación de contratos de Turing. En el diseño inicial de RGB, se afirmaba que se utilizaba un lenguaje de programación llamado Simplicity. Este lenguaje se caracteriza por generar una prueba de ejecución mientras se ejecutan expresiones, facilitando la verificación formal de los contratos escritos en él (para evitar errores). Sin embargo, el desarrollo de esta lengua no fue el ideal y eventualmente encontró dificultades. Esto condujo directamente al difícil nacimiento del protocolo RGB ese año. Finalmente, RGB empezó a utilizar AluVM, desarrollado por Maxim, con el objetivo de evitar cualquier comportamiento indefinido, similar al Simplicity inicial. Se dice que el nuevo AluVM será reemplazado en el futuro por un lenguaje de programación llamado Contractum, que actualmente usa Rust.

Dirección de expansión de la capa 2 de RGB: ¿Lightning Network o Sidechain?

Los activos validados por el cliente no pueden realizar transacciones continuas de forma segura fuera de la cadena. Debido a que los activos validados por el cliente todavía dependen de L1 para la publicación y secuenciación de transacciones, su velocidad de transacción está limitada por la velocidad de generación de bloques de su testigo L1. Esto significa que si las transacciones RGB se realizan directamente en Bitcoin, bajo estrictos requisitos de seguridad, el tiempo entre dos transacciones relacionadas debe ser de al menos diez minutos (el tiempo de bloqueo de BTC). Sin duda, esta velocidad de transacción es inaceptable en la mayoría de los casos.

RGB y la red Lightning

En pocas palabras, el principio de Lightning Network es que las dos partes involucradas en una transacción firman un conjunto de contratos (transacciones de compromiso) fuera de la cadena. Estos garantizan que si alguna de las partes viola el contrato, la parte agraviada puede enviar el contrato (transacción de compromiso) a BTC para su liquidación, recuperar sus fondos y penalizar a la otra parte. En otras palabras, Lightning Network garantiza la seguridad de las transacciones fuera de la cadena a través del diseño de protocolos y la teoría de juegos.

RGB puede construir su propia infraestructura Lightning Network diseñando reglas de contrato de canal de pago adecuadas para él, pero la complejidad de Lightning Network es extremadamente alta y construir este sistema no es una tarea fácil. Sin embargo, por el contrario, Lightnling Labs ha estado cultivando este campo durante muchos años y LND tiene más del 90% de participación de mercado.

Cadena lateral de RGB: Prime

LNP-BP, que actualmente mantiene el protocolo RGB, y Maxim lanzará una propuesta llamada Prime en junio de 2023, un esquema de expansión de activos validado por el cliente. En él, criticó los esquemas de expansión de la cadena lateral y Lightning Network existentes por ser demasiado complejos en su desarrollo. Maxim indicó que cree que además de Prime, otros métodos de expansión incluyen los canales Lightning de múltiples nodos de NUCLEUS y las fábricas de canales Ark/Enigma, los cuales requieren más de dos años de desarrollo. Sin embargo, Prime se puede completar en sólo un año.

Prime no es un diseño de cadena de bloques tradicional, sino una capa de publicación de pruebas modular diseñada para la validación del cliente y que consta de cuatro partes:

1. Servicio de marca de tiempo: determinación de una secuencia de transacción en tan solo 10 segundos.

2. Prueba: Almacenada en formato PMT, producida y publicada junto con el encabezado del bloque.

3. Sello único: un protocolo abstracto de sello único que garantiza protección contra el doble gasto. Si se implementa en Bitcoin, se puede vincular a UTXO, similar al diseño RGB actual.

4. Protocolo de contrato inteligente: contratos fragmentables - RGB (reemplazable).

Para resolver el problema de los tiempos de confirmación de transacciones RGB, Prime utiliza un servicio de marca de tiempo para confirmar rápidamente las transacciones fuera de la cadena y encapsular las transacciones y las identificaciones en bloques. Al mismo tiempo, las pruebas de transacciones en Prime se pueden fusionar aún más a través de PMT y luego anclarse a BTC de manera similar a los puntos de control.

Protocolo de activos CSV basado en Taproot: Activos Taproot

Taproot Assets es un protocolo de activos CSV basado en Taproot, que se utiliza para emitir activos validados por el cliente 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 radica en aprovechar la seguridad y estabilidad de la red Bitcoin y la velocidad, escalabilidad y bajo costo de Lightning Network. Este protocolo fue diseñado y desarrollado por el CTO roasbeef de Lightnling Labs, quien puede ser la única persona en este planeta que ha liderado personalmente el desarrollo tanto de un cliente Bitcoin (BTCD) como de un cliente Lightning Network (LND), y tiene un profundo conocimiento. de BTC.

Las transacciones Taproot solo llevan el hash raíz del script del activo, lo que dificulta que los observadores externos identifiquen si involucran Taproot Assets, ya que el hash en sí es genérico y puede representar cualquier dato. Con la actualización de Taproot, Bitcoin ganó la capacidad de contratos inteligentes (TapScript). En base a esto, la codificación de activos de Taproot Assets es similar a crear una definición de token similar a ERC20 o ERC721. Por lo tanto, Bitcoin no solo tiene la función de definir activos, sino también la capacidad de redactar contratos inteligentes, sentando las bases para la infraestructura de contratos inteligentes de tokens en Bitcoin.

La estructura de codificación de Taproot Assets es la siguiente: [La descripción termina aquí, lo que indica que la siguiente parte del artículo probablemente profundiza en los detalles técnicos de la estructura de codificación de Taproot Assets.]

Imagen vía el CTO de Lightning Labs.

Como protocolos de activos CSV (CoinSwap), los Taproot Assets están diseñados para ser más optimizados en comparación con RGB. Maximizan el uso de los avances actuales en el ecosistema BTC, como la actualización Taproot y PSBT (Transacciones Bitcoin parcialmente firmadas). La diferencia más significativa entre Taproot Assets y RGB en términos de extensibilidad de la aplicación radica en la ejecución VM (Virtual Machine). Taproot Assets emplea TaprootScriptVM, que es el mismo que la VM nativa utilizada por BTC. En los últimos años, muchos estudios de infraestructura para BTC se han basado en TapScript. Sin embargo, debido al lento ritmo de las actualizaciones de BTC, estos estudios no se implementaron rápidamente, lo que convierte a Taproot Assets en un posible campo de pruebas para estas nuevas ideas.

¿En qué se diferencian Taproot Assets y RGB?

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

Debido a la implementación de un árbol de suma, Taproot Assets cuenta con una alta eficiencia y seguridad de verificación (la verificación y la transacción se pueden realizar simplemente con una prueba de tenencia, sin recorrer todo el historial de transacciones). Por el contrario, el uso por parte de RGB de los compromisos de Pedersen dificulta la validación efectiva de los datos de entrada, lo que requiere que RGB rastree el historial de transacciones, lo que se convierte en una carga significativa con el tiempo. El diseño del árbol de suma de Merkel también facilita la verificación de nodos ligeros en Taproot Assets, una característica que no está presente en protocolos de activos anteriores creados en BTC.

1. Máquina virtual de ejecución

Taproot Assets surgió después de la actualización de Taproot. Utilizan TaprootScriptVM, el motor de ejecución de scripts inherente a la actualización post-Taproot de Bitcoin, y vPSBT, una variante del PSBT de BTC. Una vez que se completa el mecanismo del canal Lightning de Taproot Assets, puede reutilizar inmediatamente toda la infraestructura LND actual y los productos anteriores de Lightning Labs (LND actualmente domina más del 90% de la red Lightning). La reciente propuesta de BitVM, también basada en TaprootScript, teóricamente admite Taproot Assets. Sin embargo, la VM y las reglas de validación (SCHEMA) de RGB son independientes, formando un ecosistema relativamente cerrado. El desarrollo de RGB se limita en gran medida a su ecosistema y su integración con el ecosistema Bitcoin no es tan estrecha como podría pensarse. Por ejemplo, la única relación de RGB con la actualización Taproot es codificar datos de compromiso de cadena en TapLeaf del Testigo.

1. Contratos inteligentes

En la implementación actual de RGB, se hace mucho hincapié en los contratos y la VM. Sin embargo, los contratos inteligentes aún no han aparecido en Taproot Assets. Actualmente, RGB no explica cómo las modificaciones al Estado Global se sincronizan con los fragmentos de contratos individuales (UTXO), ni cómo los compromisos de Pedersen, que sólo aseguran la cantidad total de activos, detectan la manipulación con otros estados. Por el contrario, Taproot Assets, con su diseño más simple, actualmente solo almacena saldos de activos y carece de un almacenamiento estatal extenso, lo que hace que la discusión sobre contratos inteligentes sea prematura. Sin embargo, Lightning Labs ha indicado que Taproot Assets se centrará en el diseño de contratos inteligentes el próximo año.

1. Centro de sincronización

Como se entiende a partir de los principios básicos de la verificación de activos del lado del cliente, tener la Prueba es tan importante como tener la clave privada. Pero ¿qué pasa si la prueba se pierde en el lado del cliente del usuario? En Taproot Assets, este problema se puede abordar a través de un "universo". El Universo es un árbol Merkle disperso públicamente auditable, que cubre uno o más activos. A diferencia de los árboles de activos Taproot convencionales, el Universo no alberga activos Taproot. En cambio, se compromete con un subconjunto de uno o más historiales de activos. En RGB, este papel lo desempeña Storm, que sincroniza datos de prueba fuera de la cadena a través de P2P. Sin embargo, debido a razones históricas de los equipos de desarrollo de RGB, estos formatos de prueba son actualmente incompatibles. Según se informa, el equipo del ecosistema de RGB, DIBA, está desarrollando 'carbonado' para resolver este problema, aunque el progreso no está claro.

1. Implementación de ingeniería

Todas las bibliotecas utilizadas por Taproot Assets están probadas en el tiempo, ya que Lightning Labs tiene su propio cliente Bitcoin (BTCD), cliente Lightning Network (LND) y numerosas implementaciones de bibliotecas de billetera. Por el contrario, la mayoría de las bibliotecas utilizadas en RGB están autodefinidas y, desde el punto de vista de un estándar industrial, la implementación de RGB aún se encuentra en la etapa experimental”.

Una breve discusión sobre el futuro de la expansión de BTC

A medida que avanza la discusión, se hace evidente que la validación de protocolos de activos por parte del cliente ha ido más allá del ámbito de las especificaciones de protocolo y se está aventurando hacia la expansión computacional.

Mucha gente cree que Bitcoin existirá como oro digital en el futuro, y que otras cadenas crearán el ecosistema de aplicaciones. Sin embargo, tengo una opinión diferente. Como se ve en muchas discusiones en los foros de BTC, a menudo giran en torno a varias altcoins y su corta existencia. La rápida desaparición de estas altcoins convierte el capital y los esfuerzos que las rodean en burbujas. Con la sólida base de consenso de Bitcoin, no hay necesidad de crear una nueva L1 para los protocolos de aplicación. Lo que debemos hacer es aprovechar esta sólida infraestructura de Bitcoin para construir un mundo descentralizado a más largo plazo.

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

Desde una perspectiva de diseño, Bitcoin decidió desde el principio no centrarse en la computación en cadena, sino en una filosofía centrada en la validación (integridad y estado de Turing para contratos inteligentes). Blockchain es esencialmente una máquina de estados replicada. Si el consenso de una cadena se basa en cálculos dentro de la cadena, es difícil justificar la lógica y la escalabilidad de que todos los nodos de la red repitan estos cálculos. Si nos centramos en la validación, entonces validar la efectividad de las transacciones fuera de la cadena podría ser la estrategia de expansión más adecuada para BTC.

¿Dónde ocurre la validación? Esto es importante

Para los desarrolladores de protocolos además de Bitcoin, cómo utilizar Bitcoin para validaciones críticas, o incluso para colocar validaciones fuera de la cadena, y cómo diseñar esquemas de seguridad, son cuestiones que corresponden a los propios diseñadores de protocolos. Estos no deben ni necesitan estar asociados con la cadena misma. Por lo tanto, la forma en que se implemente la validación conducirá a diferentes estrategias de expansión para BTC.

Según la perspectiva de la implementación de la validación, tenemos tres direcciones de expansión:

1. 1.Validación en cadena (OP-ZKP)
2. Si OP-ZKP se implementa directamente en TaprootScriptVM, significa integrar capacidades de validación de ZKP en el propio BTC, junto con algunos diseños Covenant para protocolos de liquidación, creando un plan de expansión Zk-Rollup que hereda la seguridad de BTC. Sin embargo, a diferencia de implementar un contrato de validación en Ethereum, el lento proceso de actualización de BTC, junto con un código de operación tan especializado y que potencialmente necesita una actualización, lo convierte en un desafío.
4. 2.Validación semi-en cadena (BitVM)
5. El diseño de BitVM no pretende servir a una lógica de transacciones normal. Robin Linus también indicó 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 estos cálculos de validación no ocurren dentro de la cadena, sino fuera de la cadena. Sin embargo, una razón importante para diseñar en torno a Taproot de BTC es utilizar TapScriptVM para la validación computacional cuando sea necesario, heredando teóricamente la seguridad de BTC. Este proceso también genera una cadena de confianza de validación. Por ejemplo, es suficiente si uno de los 'n' validadores es honesto, similar a los Optimistic Rollups.
6. Los costos en cadena de BitVM son altos, pero ¿puede utilizar las pruebas de fraude de ZK para mejorar la eficiencia? La respuesta es no, porque la implementación de pruebas de fraude ZK se basa en la capacidad de realizar la validación ZKP en cadena, lo que nos devuelve al dilema del esquema OP-ZKP.
8. 3.Validación fuera de la cadena (validación del lado del cliente, Lightning Network)
9. Dado que la validación se realiza completamente fuera de la cadena, volvemos a los protocolos de activos CSV discutidos anteriormente y Lightning Network. En discusiones anteriores, se señaló que en el diseño CSV, no podemos evitar por completo la manipulación colusoria. Lo que podemos hacer es utilizar criptografía y diseño de protocolos para mantener el daño de la colusión maliciosa dentro de un rango controlable, haciendo que dicho comportamiento no sea rentable.
10. Los pros y los contras de la validación fuera de la cadena son claros. La ventaja es el uso mínimo de recursos en cadena, con un enorme potencial de expansión. La desventaja es que es casi imposible aprovechar plenamente la seguridad de BTC, lo que limita en gran medida los tipos y métodos de transacciones fuera de la cadena. Además, la validación fuera de la cadena también significa que los datos se mantienen fuera de la cadena y son administrados por los usuarios, lo que exige mayores requisitos para la seguridad del entorno de ejecución del software y la estabilidad del software.

Tendencia de evolución de la expansión

Actualmente, el popular Layer2 en Ethereum, en esencia, utiliza Layer1 para validar la efectividad computacional de Layer2. Es decir, los cálculos de estado se envían a la Capa 2, pero la validación permanece en la Capa 1. En el futuro, podremos de manera similar reducir los cálculos de validació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.