Enlace original en inglés: https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2
En el mundo blockchain actual, existen dos métodos principales de mantenimiento de registros, el modelo UTXO (Salida de transacciones no gastadas) y el modelo de cuenta. Bitcoin usa el modelo UTXO y Ethereum usa el modelo de cuenta.
Bitcoin se diseñó originalmente como un sistema de efectivo electrónico de igual a igual. En Bitcoin, cada transacción consume el UTXO generado por la transacción anterior y luego genera un nuevo UTXO. El saldo de la cuenta es el conjunto de todos los UTXO no gastados que pertenecen a la misma. dirección El estado global de Bitcoin es una colección de todos los UTXO actualmente no gastados. Ethereum tiene la intención de crear un protocolo más general que admita lenguajes de programación completos de Turing, en los que los usuarios puedan escribir contratos inteligentes y crear varias aplicaciones descentralizadas. Debido a las deficiencias del modelo UTXO en cuanto a preservación del estado y programabilidad, Ethereum introdujo el modelo de Cuenta.
A continuación ampliamos más las ventajas y desventajas de los dos modelos.
modelo UTXO
En el modelo UTXO, las transacciones solo representan cambios en la colección UTXO. Los conceptos de cuentas y saldos son abstracciones superiores en las colecciones UTXO, y los conceptos de números de cuentas y saldos solo existen en billeteras.
ventaja:
El cálculo se realiza fuera de la cadena y la transacción en sí es tanto el resultado como la prueba. El nodo solo necesita realizar verificación, no necesita realizar cálculos adicionales en la transacción y no hay almacenamiento de estado adicional. El cálculo del UTXO de salida de la transacción en sí se completa en la billetera, de modo que la carga computacional de la transacción recae completamente en la billetera, lo que reduce la carga sobre la cadena hasta cierto punto.
A excepción de las transacciones de Coinbase, la entrada de la transacción siempre está vinculada detrás de un UTXO. Las transacciones no se pueden reproducir, y la secuencia y las dependencias de las transacciones se pueden verificar fácilmente, y también se puede probar fácilmente si las transacciones se han consumido.
El modelo UTXO no tiene estado y es más fácil de procesar al mismo tiempo.
Mejor privacidad para transacciones tipo P2SH. Las entradas de la transacción no están relacionadas entre sí y se pueden utilizar tecnologías como CoinJoin para aumentar cierto grado de privacidad.
defecto:
No puede implementar alguna lógica más compleja y tiene poca programabilidad. Para lógicas complejas o contratos que requieren preservación estatal, la implementación es difícil y la utilización del espacio estatal es relativamente baja.
Cuando haya más entradas, la cantidad de guiones de testigos también aumentará. La firma en sí consume más CPU y espacio de almacenamiento.
Modelo de cuenta
Para el modelo de Cuenta, el modelo de Cuenta guarda el estado mundial y el estado de la cadena generalmente se acuerda en forma de StateRoot y ReceiptRoot en el bloque. La transacción es sólo el evento en sí y no contiene el resultado. El consenso de la transacción y el consenso del Estado pueden aislarse esencialmente.
ventaja:
El contrato se almacena en la Cuenta en forma de código y la Cuenta tiene su propio estado. Este modelo tiene mejor programabilidad, es más fácil de entender para los desarrolladores y tiene una gama más amplia de escenarios.
Las transacciones masivas son menos costosas. Imagine que el grupo de minería paga a los mineros una tarifa de manejo en UTXO, debido a que cada entrada y salida requieren un script de testigo o un script de bloqueo separado, la transacción en sí será muy grande y la verificación de firmas y el almacenamiento de transacciones consumirán recursos valiosos en la cadena. . El modelo de Cuenta puede reducir en gran medida los costos a través de contratos.
defecto:
No existe dependencia entre las transacciones del modelo de cuenta y es necesario resolver el problema de reproducción.
Para la implementación de Lightning Network / Thunder Network, Plasma, etc., se requiere un mecanismo de prueba de prueba más complejo para la prueba del usuario, y se requiere un protocolo más complejo para la migración de estado de las subcadenas a la cadena principal.
Cuenta UTXO VS
Hagamos un análisis y comparación de las ventajas y desventajas anteriores.
Primero, en cuanto a cuestiones de cálculo.
La transacción UTXO en sí no tiene cálculos complicados para la cadena de bloques. En pocas palabras, no es completamente precisa. Primero, la mayoría de las transacciones de Bitcoin son P2SH y el script Witness no está completo en Turing. existe una declaración de bucle. Para el modelo de cuenta, como Ethereum, dado que la mayoría de los cálculos se realizan en la cadena y son completos de Turing, los cálculos son generalmente más complejos y la seguridad del contrato puede convertirse fácilmente en un problema relativamente grande. Por supuesto, si Turing está completo o no no tiene relación directa con si se trata de un modelo de cuenta. Pero una vez introducido el modelo de cuenta, el contrato puede existir como una entidad independiente que no está controlada por nadie, lo cual es de gran importancia.
En segundo lugar, con respecto a la cuestión de que UTXO es más fácil de concurrir.
En el modelo UTXO, el estado mundial es una colección de UTXO. Para verificar las transacciones más rápidamente, los nodos necesitan almacenar los índices de todos los UTXO en la memoria, por lo que los UTXO son muy costosos. Los UTXO que no se consumen durante mucho tiempo siempre ocuparán la memoria del nodo. Por lo tanto, para este modelo, en teoría se debería alentar a los usuarios a producir menos UTXO y consumir más UTXO. Sin embargo, si desea utilizar UTXO para transacciones paralelas, necesita más UTXO como entrada y, al mismo tiempo, debe generar más UTXO para garantizar la concurrencia. Esto es esencialmente un ataque de polvo en la red. Y dado que las transacciones se construyen dentro de la billetera, se requiere un diseño más complejo de la billetera. Mirando hacia atrás en el modelo de Cuenta, cada cuenta puede considerarse como una máquina de estado separada que no se afecta entre sí, y las cuentas se comunican a través de mensajes. Por lo tanto, en teoría, cuando un usuario inicia múltiples transacciones y estas transacciones no se llaman entre sí la misma Cuenta, las transacciones se pueden ejecutar simultáneamente.
En tercer lugar, con respecto a la cuestión de la repetición de transacciones del modelo de Cuenta
Ethereum utiliza el método de agregar nonce en la cuenta. Cada transacción corresponde a un nonce, y el nonce se incrementa cada vez. Aunque este método está destinado a resolver el problema de la reproducción, también introduce problemas secuenciales y hace que las transacciones no se puedan paralelizar. Por ejemplo, en Ethereum, un usuario envía múltiples transacciones. Si la primera transacción no se empaqueta, las transacciones posteriores no se empaquetarán correctamente. En CITA, utilizamos un esquema nonce aleatorio, de modo que no haya una dependencia secuencial entre las transacciones de los usuarios, lo que no causará fallas en serie y también hace posible que las transacciones se procesen en paralelo.
Cuarto, problemas de almacenamiento.
Porque en el modelo UTXO, el estado solo se puede guardar en transacciones. El estado del modelo de cuenta se guarda en el nodo y se almacena mediante MPT en Ethereum. En el bloque, solo se requiere el consenso StateRoot. De esta manera, para los datos en cadena, el modelo de cuenta es en realidad más pequeño y la cantidad de transmisión de red es menor. Al mismo tiempo, el estado se guarda localmente en el nodo mediante MPT, que es más eficiente en el uso del espacio. Por ejemplo, si A transfiere dinero a B, si hay 2 entradas y 2 salidas en UTXO, se requieren 2 scripts de testigo y 2 scripts de bloqueo en el modelo de cuenta, solo se requiere una firma y el contenido de la transacción solo contiene la cantidad; . Después de la implementación del último Testigo Segregado, la cantidad de datos de transacciones de Bitcoin también se ha reducido considerablemente, pero de hecho, los nodos de verificación y los nodos completos aún necesitan transmitir y verificar el script de Testigo.
Quinto, para que los nodos ligeros obtengan un determinado estado de dirección, UTXO es más complicado
Por ejemplo, en una billetera, debe solicitar todos los UTXO sobre una determinada dirección desde el nodo completo. El nodo completo puede enviar algunos UTXO. Es difícil para la billetera verificar si el UTXO se ha consumido. la billetera para demostrar que el UTXO es el conjunto completo y no una colección parcial. El modelo de cuenta es mucho más simple. El estado correspondiente en Estado se encuentra en función de la dirección. La prueba del estado actual puede probar la autenticidad de los datos del contrato. Por supuesto, para UTXO, la raíz de UTXO también se puede verificar en cada bloque. Esto está relacionado con la implementación actual de Bitcoin y no es una característica de UTXO.
en conclusión
En resumen, el modelo de Cuenta tiene más ventajas en términos de programabilidad y flexibilidad en negocios simples y entre cadenas, UTXO tiene ventajas únicas e innovadoras. El modelo a elegir debe basarse en escenarios comerciales específicos.
