Como uno de los principios básicos de diseño de Bitcoin, el modelo UTXO ha sido un paradigma técnico importante en el dominio de la cadena de bloques desde sus inicios. Desempeña un papel crucial a la hora de garantizar la seguridad y la trazabilidad de las transacciones, proporcionando un camino alternativo más allá del modelo tradicional de saldo de cuentas. Con la continua evolución y expansión de la tecnología blockchain en los últimos años, el modelo UTXO en sí ha estado experimentando una constante evolución y extensión, como eUTXO, cell, lista de acceso estricto y otros.

Este artículo presenta el modelo UTXO en un lenguaje sencillo, proporcionando una breve descripción del modelo UTXO y los métodos de implementación de BTC, Sui, Cardano, Nervos y Fuel.

¿Qué es UTXO?

Para ilustrar el modelo UTXO, utilizamos un ejemplo:

Imagínese a dos individuos, Alice y Bob, cada uno con $5 inicialmente. Posteriormente, surge un conflicto y Bob le roba a Alice $ 2. Las tenencias finales de cada uno de ellos son las siguientes:

Es evidente que Alice termina con $3, y Bob finalmente se queda con $7. Este método de contabilidad elemental, similar a la aritmética, se ve comúnmente en los sistemas bancarios y se conoce como el "modelo de cuenta/saldo". En este modelo, el saldo de una cuenta existe como un único valor numérico.

Si adoptáramos un enfoque diferente al del modelo de cuenta, como usar UTXO para representar la transferencia de riqueza entre Alice y Bob, el diagrama ilustrativo tomaría una apariencia diferente:

En este punto, Alice todavía tiene $3 y Bob todavía tiene $7, pero estos $7 no están representados por un solo valor numérico. En cambio, se dividen en "$5" y "$2". ¿Te resulta poco familiar este enfoque poco convencional? Este es el método de contabilidad único conocido como UTXO.

El acrónimo en inglés UTXO significa Unspent Transaction Output (Salida de transacciones no gastadas). Bajo este enfoque contable, cada transacción on-chain se manifiesta como cambios y transferencias en UTXO. Por ejemplo, en el evento de transacción mencionado, los "$5" de propiedad inicial de Alice sirven como parámetros de entrada, etiquetados como UTXO_0, que se marcarán como gastados; Simultáneamente, el sistema genera "$2" (UTXO_1) y "$3" (UTXO_2) como parámetros de salida. UTXO_1 se transferirá a Bob, y UTXO_2 se devolverá a Alice, completando así la transferencia de riqueza entre Alice y Bob.

En el modelo UTXO, no hay conceptos explícitos de "cuentas" y "saldos". UTXO sirve como una estructura de datos que ayuda en la ejecución de transacciones, registrando información como la cantidad que representa y el índice de transacciones asociado. Cada UTXO representa una entrada de transacción no gastada, con un propietario designado. Cuando se produce una transacción, ciertos UTXO se pueden utilizar como entradas y, tras su destrucción, se generan nuevos UTXO como salidas de transacción.

Así es como Bitcoin lleva las cuentas: con cada transacción, se destruyen los UTXO antiguos y se crean otros nuevos. La cantidad total de UTXO destruidos es igual a la cantidad de UTXO recién creados (con una parte asignada como tarifas de transacción a los mineros). Esto garantiza que los fondos no puedan aumentarse arbitrariamente.

Comparación entre el modelo UTXO y el modelo de cuenta/saldo

Supongamos que un grupo de usuarios inicia un gran número de solicitudes de transacción simultáneamente. ¿Cómo se manejaría la situación utilizando el modelo UTXO en comparación con el modelo de cuenta/saldo?

En el modelo de cuenta/saldo, cada usuario tiene una cuenta con información de saldo registrada. Cuando se produce una transacción, es necesario actualizar el saldo de la cuenta correspondiente, lo que implica operaciones de "lectura" y "escritura". Sin embargo, si dos transacciones involucran la misma cuenta, a menudo se producen conflictos de lectura y escritura, lo que lleva a la contención de estados, una situación que debe evitarse.

Los sistemas de bases de datos tradicionales suelen abordar la contención de lectura y escritura con un mecanismo de "bloqueo". En este escenario, las transacciones que provocan la contención de los mismos datos a menudo deben ponerse en cola, lo que impide la ejecución simultánea y reduce la eficiencia del procesamiento de transacciones. Cuando hay un gran número de transacciones en espera de procesamiento, esto puede crear importantes cuellos de botella en el rendimiento, ya que las transacciones en disputa se enfrentan a tiempos de espera prolongados sin un procesamiento rápido.

A diferencia del modelo de saldo de cuentas, el modelo UTXO de Bitcoin está mejor equipado para manejar problemas de contención de datos. En este enfoque, la entidad de procesamiento directo de cada transacción ya no es una "cuenta" específica, sino UTXO individuales e independientes. Dado que los diferentes UTXO no interfieren entre sí, cada transacción en la red Bitcoin funciona de forma independiente. Como resultado, los nodos de la red Bitcoin pueden procesar múltiples transacciones simultáneamente sin necesidad de "bloqueos", lo que mejora significativamente el rendimiento del sistema y el rendimiento de la simultaneidad.

Además, en el modelo UTXO, las billeteras encriptadas suelen generar una nueva dirección para el usuario después de iniciar una transacción. Este enfoque mejora la privacidad, lo que hace que sea más difícil asociar una transacción con un individuo específico. Por el contrario, el modelo de cuenta/saldo, que utiliza direcciones fijas, es más susceptible al análisis de asociación.

Sin embargo, el modelo UTXO tiene sus limitaciones. Inicialmente se diseñó para facilitar transferencias de divisas sencillas y no es adecuado para manejar una lógica empresarial compleja. Si bien las funcionalidades básicas, como la firma múltiple y los bloqueos de tiempo, se pueden implementar utilizando lenguajes de scripting, la información de estado mínima que puede registrar UTXO de Bitcoin lo hace menos capaz de manejar operaciones más intrincadas.

Las limitaciones de UTXO de Bitcoin contribuyeron indirectamente a la aparición de "Ethereum". Vitalik, uno de los primeros colaboradores de Bitcoin Magazine, era muy consciente de las deficiencias de Bitcoin. El modelo de cuenta/saldo, que es más fácil de entender para la mayoría de las personas, aborda los desafíos a los que se enfrenta UTXO en el manejo de aplicaciones de estado enriquecido. Como declaró Vitalik en el documento técnico de Ethereum:

UTXO se puede gastar o no gastar; No hay oportunidad para contratos de varias etapas o scripts que mantengan cualquier otro estado interno más allá de eso. Esto dificulta la realización de contratos de opciones de varias etapas, ofertas de intercambio descentralizadas o protocolos de compromiso criptográfico de dos etapas (necesarios para recompensas computacionales seguras). También significa que UTXO solo se puede usar para construir contratos simples y únicos y no contratos "con estado" más complejos, como organizaciones descentralizadas, y hace que los metaprotocolos sean difíciles de implementar. El estado binario combinado con la ceguera al valor también significa que otra aplicación importante, los límites de retiro, es imposible.

Aplicación, Optimización y Extensión del modelo UXTO

Antes de profundizar en las diversas aplicaciones y optimizaciones del modelo UTXO, analicemos las áreas de mejora conservando sus ventajas. Estos se pueden resumir de la siguiente manera:

1. Abstraer el significado del estado almacenado en UTXOs.

2. Abstracción de la propiedad del Estado.

3. Resolución de problemas de contención de estado al compartir UTXO.

En BTC, el único significado del estado es la cantidad de tokens, la propiedad generalmente se define mediante claves públicas y la contención del estado no se aborda ampliamente ya que BTC no fue diseñado para dApps.

Sui

Sui proporciona a los desarrolladores dos tipos de objetos: OwnedObject y SharedObject. El primero es similar a UTXO (específicamente una versión mejorada), mientras que el segundo es comparable al modelo de cuenta/saldo. Ambos se pueden utilizar simultáneamente.

Un objeto se puede compartir, lo que significa que cualquiera puede leer o escribir en ese objeto. A diferencia del OwnedObject mutable (con un solo escritor), SharedObject requiere consenso para ordenar las lecturas y escrituras.

En otras cadenas de bloques, cada objeto se comparte. Sin embargo, los desarrolladores de Sui normalmente pueden optar por usar OwnedObject, SharedObject o una combinación de ambos para implementar casos de uso específicos. Esta elección puede afectar al rendimiento, la seguridad y la complejidad de la implementación.

En Sui, los objetos propios son similares a los UTXO, y solo su propietario puede operar en ellos. Los objetos también tienen números de versión, y su propietario solo puede gastar una versión de un objeto una vez. Por lo tanto, una versión de un objeto corresponde esencialmente a un UTXO.

Con respecto a los problemas de contención de estados, Sui los aborda a través de un manejo especial (ordenamiento local, similar a Fuel) en SharedObjects.

Cardano

Cardano utiliza un modelo UTXO extendido conocido como eUTXO. eUTXO admite una mayor capacidad de programación al tiempo que conserva las ventajas del modelo UTXO de Bitcoin.

En Cardano, el significado del estado se expande aún más a través de scripts, y la propiedad del estado se define de una manera más generalizada. Los conjuntos UTXO se utilizan para minimizar los problemas de contención de estados. En concreto, eUTXO se ve potenciado en dos aspectos:

1. El modelo eUTXO incluye direcciones más generalizadas. Estas direcciones no se basan únicamente en el hash de las claves públicas, sino que se pueden definir en función de cualquier lógica que especifique las condiciones en las que se puede gastar eUTXO, lo que permite la programabilidad de la propiedad estatal.

2. Además de las direcciones y los valores, las salidas pueden llevar (casi) cualquier dato, lo que permite programar el significado del estado a través de scripts.

Más específicamente, eUTXO permite a los usuarios agregar datos arbitrarios en un formato similar a JSON a UTXO, denominados Datum. Datum permite a los desarrolladores proporcionar una funcionalidad similar a la de un estado para scripts, asociados con UTXO específicos.

Además, las transacciones en Cardano pueden llevar parámetros relacionados con usuarios específicos, conocidos como canjeadores. Redeemer permite al iniciador de la transacción definir cómo se utilizan los UTXO y puede ser empleado por los desarrolladores de dApps para diversos fines.

Cuando se valida una transacción, el script de validación funciona con Datum, Redeemer y el contexto que contiene los datos de la transacción. Este script incluye la lógica para usar UTXO cuando se cumplen las condiciones.

Vale la pena señalar que eUTXO todavía realiza tareas de extensión a través de scripts y difiere significativamente de la noción tradicional de "contratos inteligentes" (Charles Hoskinson, el fundador, sugiere llamarlo "validador programable", pero el término "contratos inteligentes" es más ampliamente aceptado en el mercado).

Nervos

En Nervos (CKB), el significado del estado se abstrae mediante TypeScript y la propiedad del estado se abstrae mediante un script de bloqueo. Un modelo de optimización UTXO simple en forma de código de celda es el siguiente:

pub struct CellOutput {

    Capacidad del pub: Capacidad,

datos de pub: Vec,

pub lock: Script,

pub type_: Opción< Guión>,

}

En cuanto a la cuestión de la contención estatal, CKB está avanzando actualmente en la investigación sobre la transacción abierta, en la que los usuarios pueden proponer un UTXO parcial que especifique el propósito de la transacción y luego los emparejadores los agreguen en una transacción completa.

El modelo celular de Nervos es una versión "generalizada" de UTXO, y Jan proporcionó una explicación detallada en el foro de Nervos:

El enfoque de Layer1 está en el estado, y con Layer1 como destino de diseño, CKB se centra naturalmente en el estado.

Ethereum separa el historial de transacciones y el historial de estado en dos dimensiones, donde los bloques y las transacciones representan eventos que desencadenan transiciones de estado en lugar del estado en sí. Por el contrario, el protocolo Bitcoin fusiona las transacciones y los estados en una sola dimensión: las transacciones son el estado y el estado es la transacción. Es una arquitectura centrada en el estado.

Al mismo tiempo, CKB tiene como objetivo verificar y preservar no solo nValue como estado, sino cualquier dato que se considere valioso y aprobado por consenso para su preservación a largo plazo. La estructura de salida de transacciones de Bitcoin es inadecuada para este propósito, pero nos ha proporcionado una amplia inspiración. Al generalizar nValue y transformarlo de un espacio que almacena números enteros en un espacio capaz de contener cualquier dato, obtenemos un "CTxOut" o Cell más generalizado.

En una celda, nValue se convierte en dos campos: capacidad y datos. Estos campos representan conjuntamente un espacio de almacenamiento, donde la capacidad es un número entero que indica el tamaño del espacio en bytes, y los datos son donde se almacena el estado y puede acomodar cualquier secuencia de bytes. La scriptPubKey se convierte en bloqueo, solo un cambio de nombre, que expresa quién es el propietario de este espacio de consenso: solo la persona que puede proporcionar parámetros (como una firma) para hacer que el script de bloqueo se ejecute correctamente puede "actualizar" el estado en esta celda. El número total de bytes ocupados por todo CellOutput debe ser menor o igual que la capacidad. CKB tiene numerosas células, y su colección forma el estado actual completo de CKB, almacenando conocimiento compartido en lugar de solo una moneda digital específica.

Las transacciones siguen representando cambios/migraciones del estado. El cambio de estado o la "actualización" del contenido de la célula se logra realmente a través de la destrucción y la creación (no modificando directamente el contenido de la célula original). Cada transacción destruye efectivamente un lote de celdas y, al mismo tiempo, crea un nuevo lote de celdas. Las celdas recién creadas tienen nuevos propietarios y almacenan nuevos datos, pero la capacidad total destruida siempre es mayor o igual que la capacidad total creada, lo que garantiza que nadie pueda aumentar arbitrariamente la capacidad. Dado que la capacidad se puede transferir pero no aumentar arbitrariamente, poseer capacidad equivale a poseer una cantidad correspondiente de espacio de estados de consenso. La capacidad es el activo nativo de la red CKB. La destrucción de una célula simplemente la marca como "destruida", de forma similar a cómo los UTXO de Bitcoin no gastados se gastan y no se eliminan físicamente de la cadena de bloques. Cada celda solo se puede destruir una vez, al igual que cada UTXO solo se puede gastar una vez.

Las características de este modelo son:

1. El Estado es de primordial importancia.

2. La propiedad es un atributo del estado, y cada estado tiene un solo propietario.

3. Los Estados se destruyen y crean continuamente.

Por lo tanto, una célula es una versión generalizada de UTXO.

Combustible

Fuel adopta el modelo de Lista de Acceso Estricto, que es una optimización UTXO basada en el concepto de Contrato UTXO.

Como se presentó anteriormente, UTXO tradicional en BTC solo tiene dos atributos: cantidad de moneda y propietario. Por el contrario, Contract UTXO proporciona propiedades fundamentales adicionales, incluida la cantidad de monedas, el ID del contrato, el hash del código del contrato y la raíz de almacenamiento.

Si se utiliza un modelo de ejecución sin estado, solo Contract UTXO requiere un hash de código de contrato y una raíz de almacenamiento. En un modelo de ejecución con estado, estos campos se pueden omitir en UTXO de contrato, pero se necesita un tipo UTXO de elemento de almacenamiento independiente. El ID de UTXO, un identificador único para cada UTXO que sirve como clave en una base de datos de almacenamiento de clave-valor, se genera a partir del punto de salida del UTXO o su variante (por ejemplo, hash del punto de salida y sus campos).

En este modelo, los contratos UTXO, similares a los contratos inteligentes, pueden ser llamados por cualquiera.

Es esencial tener en cuenta que Fuel proporciona funcionalidades más cercanas a los contratos inteligentes que a los scripts. Las limitaciones del propio modelo UTXO hacen que el desarrollo de aplicaciones con una máquina virtual sea un reto, especialmente en el manejo de problemas de contención de UTXO. Por lo general, hay tres soluciones: en primer lugar, el proceso fuera de la cadena, como en el rollup; en segundo lugar, el trabajo adicional de presecuenciación, que emplea Fuel; en tercer lugar, la mencionada Transacción Abierta en CKB, donde cada usuario puede proponer transacciones parciales, y un matchmaker (similar a un secuenciador) las combina en transacciones completas. La solución correspondiente en BTC es PBST.

Conclusión

A partir de este artículo, hemos obtenido una comprensión de los principios fundamentales de UTXO, hemos reconocido las fortalezas y debilidades de su modelo en comparación con el modelo de cuenta/saldo de Ethereum y hemos obtenido una visión más clara del concepto de UTXO y sus extensiones relacionadas.

Como uno de los principios básicos de diseño de Bitcoin, el modelo UTXO desempeña un papel crucial para garantizar la seguridad y la trazabilidad de las transacciones. Con la continua evolución y expansión de la tecnología blockchain, se ha ido desarrollando el modelo UTXO (como EUTXO, célula, Lista de Acceso Estricto), proporcionando más posibilidades para la transacción y gestión de activos digitales. A través de la investigación en profundidad y la comprensión del concepto UTXO y sus extensiones relacionadas, podemos comprender mejor la esencia de la tecnología blockchain, sentando una base más sólida para futuras innovaciones y aplicaciones.

Renuncia:

1. Este artículo es una reimpresión de [极客 Web3], Todos los derechos de autor pertenecen al autor original [0xAyA]. 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 son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.