|
Inspirado por muchos [[Código abierto|proyectos de código abierto]], Cardano no comenzó con un [[plan de programación]] definido (''Roadmap'') o incluso con un [[Libro blanco]] (''White paper''). Más bien, adoptó una colección de principios de diseño, mejores prácticas de ingeniería y vías de exploración. Luego de mucha investigación, Cardano presentó un plan de programación que es un resumen del desarrollo que se desplegaría en los siguientes años. El plan de programación se definió en '''cinco grandes eras:'''<ref>{{Cita web|url=https://roadmap.cardano.org/en/|título=Cardano roadmap|fechaacceso=2022-07-01|sitioweb=Cardano roadmap|idioma=en}}</ref>
=== Byron ===
La primera era de Cardano permitió a los usuarios comprar y vender la '''Criptomoneda Ada''' en una red federada ejecutando un innovador protocolo de consenso. '''Ouroboros''', el corazón de la red de Cardano, es el primer protocolo de prueba de participación creado sobre la base de investigaciones académicas, con un nivel de seguridad probado matemáticamente.<ref name="Sin_nombre-p5Ik-4">{{Cita web|url=https://roadmap.cardano.org/en/byron/|título=Byron|fechaacceso=2022-07-01|sitioweb=Cardano roadmap|idioma=en}}</ref>La era Byron también vio la entrega de la billetera '''Daedalus''', la billetera de escritorio oficial de IOHK para ada, así como '''Yoroi''', una billetera liviana desarrollada por Emurgo, diseñada para transacciones rápidas y uso diario. La era Byron trató de los primeros desarrollos tecnológicos cruciales, también de construir una comunidad e involucrar a diferentes personas en la creación de la cadena de bloques.<ref name="Sin_nombre-p5Ik-4" />
=== Shelly ===
Fue un período de crecimiento y desarrollo para la red. A diferencia de la era Byron, que comenzó instantáneamente cuando se lanzó la red principal, la transición a Shelley estaba diseñada para lograr una transición suave y de bajo riesgo, sin interrupciones del servicio. La era Shelley abarco los primeros pasos críticos en el despliegue de Cardano para optimizar la descentralización, estos fueron graduales pero significativos.<ref name="Sin_nombre-p5Ik-5">{{Cita web|url=https://roadmap.cardano.org/en/shelley/|título=Shelley|fechaacceso=2022-07-01|sitioweb=Cardano roadmap|idioma=en}}</ref> Durante la era de Byron, la red estaba federada, pero a medida que avanzó la era de Shelley, más y más nodos pasaron a ser administrados por la comunidad de Cardano. Una vez que la mayoría de los nodos estuvieron a cargo de los participantes de la red, Cardano ganó más descentralización y como resultado, ganó una mayor seguridad y solidez. Shelley también introdujo un '''esquema de delegación e incentivos''', un sistema de recompensas para impulsar la adopción de la comunidad. Como red de [[prueba de participación]] (PoS), los usuarios delegan su ADA para participar en la red. El esquema de delegación e incentivos ha permitido y recompensado a los usuarios por delegar sus Adas en Stake pools (nodos de red administrados por la comunidad que están siempre activos) y por su participación asegurando la blockchain. Llegado el final de la era Shelley, Cardano ganó entre 50 a 100 veces más [[descentralización]], logró alcanzar 1000 grupos de participación (Stake pools). Las blockchain prominentes actuales como [[Bitcoin]] o [[Ethereum]] a menudo están controladas por menos de 10 grupos de minería<ref>{{Cita web|url=https://www.forbes.com/sites/rogerhuang/2021/12/29/the-chinese-mining-centralization-of-bitcoin-and-ethereum/|título=The ‘Chinese Mining Centralization’ Of Bitcoin And Ethereum|fechaacceso=2022-07-01|apellido=Huang|nombre=Roger|sitioweb=Forbes|idioma=en}}</ref><ref>{{Cita web|url=https://media.consensys.net/are-miners-centralized-a-look-into-mining-pools-b594425411dc|título=Are Miners Centralized? A Look into Mining Pools|fechaacceso=2022-07-01|apellido=alethio|fecha=2018-05-09|sitioweb=Medium|idioma=en}}</ref><ref>{{Cita noticia|título=Bitcoin’s Network Operations Are Controlled by Five Companies|url=https://www.bloomberg.com/news/articles/2020-01-31/bitcoin-s-network-operations-are-controlled-by-five-companies|periódico=Bloomberg.com|fecha=2020-01-31|fechaacceso=2022-07-01|idioma=en}}</ref><ref>{{Cita web|url=https://www.extremetech.com/extreme/184427-one-bitcoin-group-now-controls-51-of-total-mining-power-threatening-entire-currencys-safety|título=One Bitcoin group now controls 51% of total mining power, threatening entire currency's safety - ExtremeTech|fechaacceso=2022-07-01|sitioweb=www.extremetech.com}}</ref><ref>{{Cita web|url=https://www.techspot.com/news/91937-bitcoin-largely-controlled-small-group-investors-miners-study.html|título=Bitcoin is largely controlled by a small group of investors and miners, study finds|fechaacceso=2022-07-01|sitioweb=TechSpot|idioma=en-US}}</ref>, lo que las expone a un grave riesgo de compromiso por comportamiento malicioso, algo que Cardano evita con un sistema inherentemente diseñado para fomentar una mayor descentralización.<ref name="Sin_nombre-p5Ik-5" />
=== Goguen ===
Con la integración de [[Contrato inteligente|contratos inteligentes]], la era Goguen representó un gran avance en la capacidad tecnológica de la red Cardano. En la era Shelley se descentralizó el núcleo del sistema, luego en Goguen se agregó la capacidad de crear aplicaciones descentralizadas(DApps). La construcción de Goguen estuvo en marcha en paralelo con Shelley y al ser lanzado permitió a los usuarios con antecedentes técnicos y no técnicos generar y ejecutar contratos inteligentes funcionales en la red de Cardano. Uno de los objetivos de la era Goguen fue la creación de '''Plutus''', una plataforma de ejecución y un lenguaje computacional que permite el desarrollo de contratos inteligentes, Plutus fue especialmente diseñado para Cardano utilizando el lenguaje de programación funcional [[Haskell]]. Plutus está disponible para pruebas y trae los beneficios de la [[programación funcional]] a la creación de contratos inteligentes. También permite que una base de código admita componentes dentro y fuera de la cadena, lo que mejora la coherencia y la facilidad de uso de la experiencia de desarrollo en comparación con las implementaciones de contratos inteligentes existentes.<ref name="Sin_nombre-p5Ik-6">{{Cita web|url=https://roadmap.cardano.org/en/goguen/|título=Goguen|fechaacceso=2022-07-01|sitioweb=Cardano roadmap|idioma=en}}</ref> La era Goguen también abarca el trabajo para hacer que Cardano sea accesible a un público más amplio a través de '''Marlowe''', lo que permite a los expertos financieros y comerciales sin conocimientos técnicos previos producir contratos inteligentes. Marlowe es un [[lenguaje específico de dominio]] (DSL) de alto nivel para contratos financieros que se basa en Plutus. Marlowe viene con '''Marlowe Playground''', una plataforma de creación de aplicaciones fácil de utilizar que los no programadores pueden usar para generar contratos financieros inteligentes. Juntos, Marlowe y Marlowe Playground simplifican el proceso de creación de contratos inteligentes para aplicaciones financieras, lo que permite que los expertos en la materia contribuyan directamente sin necesidad de conocimientos profundos de programación. La combinación de Plutus y Marlowe permitirá una nueva clase de contratos inteligentes de nivel empresarial con funcionalidad verificada, capaz de sustentar implementaciones a gran escala en el mundo real.<ref name="Sin_nombre-p5Ik-6" /> Además de implementar funcionalidad en forma de contratos inteligentes, Goguen también mejoro el núcleo de Cardano. La adición de un '''libro de contabilidad de múltiples monedas''' amplio aún más la utilidad de Cardano, lo que permitió a los usuarios crear '''nuevos tokens''' compatibles de forma nativa. Habilito la creación de tokens fungibles y no fungibles ([[Token no fungible|NFTs]]), apoyando la creación de nuevas criptomonedas en el interior de Cardano, así como la tokenización de muchos tipos de activos digitales y físicos. Otro beneficio fue una integración más fácil de contratos inteligentes y ''Dapps'' que involucran múltiples criptomonedas.<ref name="Sin_nombre-p5Ik-6" />
[[Archivo:Consensus 2022, Cardano.jpg|miniaturadeimagen|Comunidad de Cardano en el evento internacional de CoinDesk: Consensus 2022. Austin, Texas.|270x270px]]
=== Basho ===
En lugar de requerir que los nodos estén en línea todo el tiempo, Ouroboros BFT asumió una '''red federada de servidores''' y comunicación sincronizada para construir la cadena de bloques. Este escenario federado es un protocolo de consenso que resulta atractivo por su sencillez y '''carácter determinista'''. Vale la pena señalar que BFT requirió una fracción mayor de partes honestas que otras versiones de Ouroboros.
El protocolo es ejecutado por '''(n)''' servidores sobre una red sincronizada y puede tolerar cualquier número '''(t)''' de fallas bizantinas con '''t n/3'''. Además, el protocolo puede ofrecer un procesamiento de transacciones a la máxima velocidad de la red en caso de que no se produzcan fallas, se generara una confirmación instantánea: el cliente puede estar seguro en un solo tiempo de ida y vuelta de que se liquidará una transacción enviada, y una prueba instantánea de liquidación aparecerá: el cliente puede obtener un recibo de que se liquidará una transacción presentada. También se puede derivar fácilmente un protocolo de consenso binario. Se analizó el protocolo en caso de rupturas de red y pérdida temporal de sincronía argumentando la seguridad del protocolo cuando se restablecía la sincronía. Finalmente, se examinó el modelo contradictorio encubierto que muestra que la resiliencia bizantina aumenta a t '''n/2.'''<ref>{{Cita web|url=https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/|título=Ouroboros-BFT: A Simple Byzantine Fault Tolerant Consensus Protocol}}</ref><ref>{{Cita web|url=https://iohk.io/en/blog/posts/2022/06/03/from-classic-to-chronos-the-implementations-of-ouroboros-explained/|título=From Classic to Chronos: the implementations of Ouroboros explained}}</ref>
(''[https://eprint.iacr.org/2018/1049.pdf Ver White paper de Ouroboros B.F.T]'')
=== Vasil: Plutus 2.0 y el debut de ''Pipelining'' ===
Vasil, es la actualización del protocolo que se introdujo en junio de 2022. Nombrada en honor al difunto matemático búlgaro y destacado miembro de la comunidad de Cardano, ''Vasil Dabov,'' la actualización de Vasil presenta cinco mecanismos clave para mejorar el rendimiento de la cadena de bloques: '''CIP-31''' (Entradas de referencia), '''CIP - 32''' (datos en línea), '''CIP-33''' (guiones de referencia), '''CIP-40''' (salidas colaterales) y canalización de difusión. Estas mejoras impulsan la usabilidad y escalabilidad de Cardano al aumentar el límite de tamaño de bloque para adaptarse a más transacciones por bloque. Los desarrolladores tendrán una mejor experiencia mientras construyen sobre Cardano, ya que Vasil reducirá en gran medida la complejidad de crear e implementar ''DApps'' en Cardano. Los scripts de Plutus también son un foco principal de la actualización de Vasil. Estos scripts vivirán de forma persistente en la cadena para que se pueda hacer referencia a ellos cuando sea necesario, lo que mejorará la eficiencia, ya que no será necesario incluir el script en la transacción que intenta gastar sus resultados.<ref>{{Cita web|url=https://capital.com/cardano-upgrade-vasil-hard-fork-timing-details|título=Cardano upgrade: Vasil hard fork timing and details in full}}</ref><ref>{{Cita web|url=https://www.coindesk.com/tech/2022/09/20/what-cardanos-highly-anticipated-vasil-hard-fork-will-bring/|título=What Cardano’s Highly Anticipated Vasil Hard Fork Will Bring}}</ref><ref>{{Cita web|url=https://emurgo.io/cardanos-major-network-update-what-is-the-vasil-hard-fork/|título=Cardano’s Major Network Update: What is the Vasil Hard Fork?}}</ref>
== Modelo EUTXO ==
Las redes ''[[Cadena de bloques|Blockchain]]'' son estructuras de datos complejas. Las transacciones se entrecruzan continuamente en la cadena, creando huellas digitales que requieren un seguimiento y una gestión cuidadosa para mantener la integridad y la fiabilidad del [[libro mayor]] subyacente. Toda empresa o entidad comercial requiere un balance general para mantener un registro preciso de las ganancias, pérdidas, flujo de efectivo y otros parámetros. Al mantener una [[contabilidad]] cuidadosa de todos estos datos, las empresas pueden de un vistazo visualizar su estado financiero en cualquier momento. El [[libro de contabilidad]] de una empresa ofrece otra ventaja: la capacidad de rastrear la procedencia y propiedad de los fondos. Las redes Blockchain también requieren un modelo de contabilidad para determinar quién posee ''(x)'' monedas y cuántas de ellas, rastrear a dónde van, cuáles se usaron y cuáles quedan disponibles para gastar. Hace décadas, los contadores usaban libros de contabilidad físicos con entradas escritas a mano para llevar los registros sobre el movimiento de los fondos de una entidad. Hoy en día, las empresas utilizan versiones electrónicas. Las cadenas de bloques '''usan las transacciones como registros''' (equivalente a las entradas en un libro mayor tradicional) para rastrear la procedencia y la propiedad. Estas transacciones contienen mucha información (de dónde provienen las monedas, a dónde van y cualquier cambio que quede de estas transacciones).
Existen principalmente dos tipos diferentes de libros de contabilidad usados por las cadenas de bloques: las cadenas de bloques basadas en el '''modelo UTXO''' (por ejemplo: [[Bitcoin]] y '''Cardano''') y las cadenas que utilizan un '''modelo de cuentas/saldos''' (por ejemplo: [[Ethereum]] y otras)
Cardano buscó combinar el modelo original UTXO de Bitcoin con la capacidad de Ethereum de implementar contratos inteligentes. Así Cardano desarrolló un modelo innovador de contabilidad extendido llamado '''EUTXO''' (''Extended Unspent Transaction Output'') que permite la implementación de [[Contrato inteligente|contratos inteligentes]] en el interior de la blockchain, en el caso de Cardano, es más exacto hablar de '''scripts de validación'''. El modelo (EUTXO) es importante para Cardano porque permite a la cadena ser más que una simple red transaccional.
El modelo EUTXO ofrece algunas '''ventajas''' sobre el modelo basado en cuentas. En particular, una '''mayor seguridad''' al ejecutar contratos inteligentes, '''previsibilidad de tarifas''', verificación local que garantiza que las transacciones se aceptarán después del envío y un estado de cadena de bloques inherentemente fragmentado. Esto permite la '''paralelización''' en el procesamiento de transacciones, lo que tiene un efecto positivo en la '''escalabilidad''' en cadena. La paralelización también es importante para la ejecución de contratos inteligentes. Al igual que las transacciones, los contratos inteligentes también se pueden ejecutar de forma '''independiente''', es decir, en paralelo. Al procesar contratos inteligentes, el orden en el bloque no importa, no es necesario considerar los resultados de ejecución de otros contratos en el bloque, por lo que la ejecución en sí puede considerarse '''más segura'''. En otras palabras, dado que los resultados de ejecución de contratos inteligentes individuales son independientes entre sí y '''no hay un estado mutable-global compartido''', hay menos superficie para [[Ciberataque|ataques]].
Es importante señalar que la escalabilidad de las aplicaciones descentralizadas se basa en las capacidades del modelo de contabilidad implementado. En general, los contratos inteligentes y su ejecución pueden verse como una capa que depende inherentemente de las capacidades de la cadena de bloques.
Las opciones de paralelización del modelo EUTXO de Cardano se basan en el diseño UTXO original de Bitcoin, donde cada UTXO no gastado existente se compone de una secuencia de transacciones anteriores. Entonces cada EUTXO de Cardano se puede manejar de forma independiente. No existe tal cosa como un estado global que deba tenerse en cuenta durante el manejo y la validación. Solo el estado local es lo que importa. Esto significa que el resultado de la transacción depende única y exclusivamente del uso del EUTXO, que son '''objetos inmutables de un solo uso''' que actúan como '''entrada''' de transacciones que producirán '''salidas'''. Cada transacción puede consumir uno o más EUTXO, lo que creará nuevos EUTXO que tendrán el mismo valor total. La única forma en que una transacción puede influir en el efecto de otra transacción, es intentando gastar el mismo EUTXO que la transacción posterior intenta gastar, lo que hace que el nodo la rechace.
Si una transacción pasa la validación local, el usuario puede estar casi seguro de que la transacción llegará a un nuevo bloque. Las transacciones en el modelo EUTXO de Cardano son independientes entre sí y son [[Algoritmo determinista|deterministas]], lo que significa que es muy probable que la transacción no falle. Igualmente para la validación de [[Script|scripts]] de '''Plutus''', los usuarios pueden verificar localmente que se puede enviar una secuencia de comandos de Plutus y ejecutarla en la cadena, asegurando que las tarifas nunca se pierdan. Sin embargo, se debe seguir una regla: Cada EUTXO solo se puede gastar una sola vez y en su totalidad dentro de un bloque. El gasto de un UTXO debe ser aceptado por toda la red como parte de la incorporación en un nuevo bloque. Esto significa que el destinatario del UTXO solo puede gastarlo en el siguiente bloque. No en el mismo bloque en el que se recibió el UTXO. La adición de un nuevo bloque en la cadena de Cardano puede considerarse como una transición de estado de la misma. Sin embargo, en los propios bloques, las transacciones individuales y los EUTXO son independientes entre sí.
El modelo EUTXO de Cardano es más [[Algoritmo determinista|determinista]] que el modelo basado en cuentas de [[Ethereum]], pero aún así se puede dar el caso que una transacción sea rechazada. El rechazo significa que, a pesar de que la transacción se haya construido correctamente, no se puede introducir a la cadena de bloques. Si esto sucede, la transacción no tiene efecto en el estado de la cadena de bloques, por lo que no se pagara ninguna tarifa. Se produce un rechazo de la transacción en caso de contención, esto significa, que el estado de la cadena de bloques cambió aproximadamente al mismo tiempo que el usuario construyó una transacción localmente. La validación local ha pasado, pero el estado de la [[cadena de bloques]] es diferente en el momento del envío. El determinismo asegura que, siempre que se acepte una transacción '''tendrá el mismo efecto''' en el estado del [[libro mayor]] que durante la construcción y la validación local.
Puede ser más difícil para un desarrollador crear un script de validación, ya que ellos mismos tienen que lidiar con la [[Concurrencia (informática)|concurrencia]]. Las transacciones pueden entrar en conflicto si dependen del mismo EUTXO al mismo tiempo. Por ejemplo, si algunos EUTXO estuvieran bloqueados por un contrato inteligente, '''solo un agente''' puede interactuar con ellos dentro de un bloque. Tenga en cuenta que esta limitación se aplica solo a EUTXO. Un [[contrato inteligente]] puede manejar varios UTXO diferentes que componen su estado actual y [[metadatos]] fuera de la cadena que permiten interpretar esos UTXO.
'''La paralelización''', o la capacidad de realizar múltiples operaciones independientes simultáneamente, es una característica importante en términos de '''escalabilidad y rendimiento''' general de la red de Cardano. El estado global del modelo basado en cuentas de [[Ethereum]] limita las opciones de escalabilidad, ya que es extremadamente difícil lograr la paralelización en el procesamiento de transacciones y también la ejecución de contratos inteligentes. Con el modelo EUTXO, se puede lograr un mayor nivel de [[Concurrencia (informática)|concurrencia]], lo que abre la puerta a una '''mayor escalabilidad'''.
Al igual que en [[Bitcoin]], procesar una transacción en la red de Cardano implica validar la acción solicitada. El [[Nodo (informática)|nodo]] procede a verificar que puede realizar la acción solicitada y que el autor de la transacción ha proporcionado los datos/entradas relevantes. La acción es para transacciones ordinarias que pretenden gastar EUTXO que están bloqueados con una clave pública. '''El nodo confirma''' que el autor de la transacción ha proporcionado una firma digital con la clave privada correspondiente. La acción, es decir, consumir el EUTXO, se realizará si la validación es exitosa. La siguiente acción es validar las transacciones que pretenden gastar un EUTXO que está bloqueado por una dirección de script. Un script es un programa (un fragmento de código) que decide si la transacción que gasta el EUTXO está autorizada o no para hacerlo. Un [[script]] contiene funciones puras cuyo resultado es '''Verdadero o Falso'''. Para validar una transacción, el nodo invoca el intérprete de secuencias de comandos, que es un programa que puede traducir y ejecutar el código de secuencias de comandos de Plutus. El intérprete ejecuta el script cuyo hash ha sido formado por la dirección donde están bloqueadas los UTXO. En otras palabras, cuando un EUTXO está bloqueado por una secuencia de comandos de Plutus, el código de secuencia de comandos de ese EUTXO se asocia con su dirección.
Lo que es realmente '''innovador''' sobre el modelo EUTXO de Cardano en comparación con el de [[Bitcoin]], además de la '''mayor expresividad de la programabilidad''' habilitada por Plutus, es que un UTXO extendido permite a los usuarios agregar opcionalmente datos de usuario arbitrarios en formato similar a [[JSON]] a UTXO. Este dato se llama [[Datum]]. El Datum permitirá a los desarrolladores dar a los [[Script|scripts]] una funcionalidad similar al estado. Los datos de usuario se pueden considerar como un estado de script local. Este estado solo tiene validez local, ya que está asociado a una UTXO específico. Usar todo el potencial de Datum depende de los desarrolladores. Las transacciones pueden llevar argumentos específicos del usuario, llamados '''''Redentor'''''. ''Redentor'' puede verse como la intención del autor de la transacción sobre cómo gastar el UTXO. '''''Redeemer''''' puede ser utilizado por [[Desarrollador de software|desarrolladores]] de aplicaciones descentralizadas para varios propósitos. Por lo general, existe una vinculación entre ''Datum'' y ''Redeemer'' que depende de la funcionalidad específica de una aplicación en particular. Cuando se valida una transacción, un script de validación opera con Datum, Redentor y un contexto que incluye datos de la transacción. El script contiene condiciones que permiten consumir el UTXO cuando se cumplen. El contexto de Datum, Redentor y transacción son datos que se ingresan al script.
Para gastar los EUTXOs que están bloqueados por una secuencia de comandos, primero es necesario colocar la secuencia de comandos en la cadena de bloques. El desbloqueo de la UTXO dependerá del script, por lo que la transacción contendrá el script y también las UTXO que se bloquearán. Los desarrolladores (o sus aplicaciones) escriben el código en cadena de Plutus y lo empaquetan en un formato especial. Luego, se debe crear una transacción en la que se incrustará el script de Plutus. Una vez que la transacción se ha almacenado en la cadena de bloques, se puede enviar otra transacción para iniciar la ejecución del script. La transacción se puede ver como un mensaje al script. Los desarrolladores dividen las aplicaciones en código dentro y fuera de la cadena. El código fuera de la cadena puede ser parte de la billetera o puede ser una [[aplicación descentralizada]] ('''DEX'''). La parte fuera de la cadena de la aplicación puede crear una transacción que contenga el script en la cadena y los EUTXO que deben bloquearse. Para cada EUTXO se debe especificar el [[Función hash|hash]] de Datum. El usuario tiene que firmar la transacción. Después de que la red envíe y acepte la transacción, el script bloqueará los EUTXO.
La validación de un script requiere muchos más recursos que la validación de una transacción normal. En [[Ethereum]] una fuente de indeterminismo puede ser el tamaño de las tarifas (''fees'') de ejecución del guion/contrato inteligente. En el caso de Cardano, el presupuesto para ejecutar el guion es parte de la transacción y es posible calcular la tarifa exacta localmente por adelantado. El intérprete del script realiza un seguimiento del consumo de los recursos durante la ejecución del script en el contexto del presupuesto. Si se agota el presupuesto de ejecución, la evaluación del script se detiene y el resultado es '''Falso'''. Un valor falso significa que no se consumirá el EUTXO. Tenga en cuenta que un script de Plutus solo funciona con el estado asociado del EUTXO y, además, con los datos que recibe en la transacción. La ejecución del script no depende de nada más. Lo único que cambiará desde la perspectiva del libro mayor a nivel global es el movimiento de los EUTXOs entre direcciones con cada bloque agregado en la cadena. El mismo contrato se puede usar para bloquear las monedas de los agentes ''A y B''. Ejecutar el script para las monedas de ''(A)'' no tiene ningún efecto sobre la ejecución del script para las monedas de ''(B)'', ya que son dos ejecuciones independientes para EUTXOs separados. El resultado de las dos ejecuciones individuales depende de los estados locales. Se construye entonces una transacción de gasto (transacción de mensaje) para interactuar con el script. La entrada de la transacción puede ser el EUTXO que está bloqueado por el script. La transacción de gasto invoca el intérprete de guiones para validar el guion y desbloquear el EUTXO si se cumplen las condiciones. Por lo tanto, el EUTXO desbloqueado se transfiere a una nueva dirección.
Algunas aplicaciones pueden necesitar trabajar con un estado global a través de múltiples EUTXO y pueden usar Datum para hacerlo. Se puede lograr una especie de estado global dentro de un diseño de protocolo particular. Los diseñadores de protocolos deben ser conscientes de que si los EUTXO están bloqueados por un script, solo un único agente puede interactuar con él dentro de un bloque. Esto puede requerir algún tipo de sincronización entre agentes.
Por ejemplo: Los fondos de liquidez que usa ''(x)DEX'' son recursos compartidos porque los usuarios quieren usarlos al mismo tiempo (dentro del mismo bloque). Cada grupo de liquidez contiene un conjunto de EUTXO. Por lo tanto, los EUTXO disponibles también son recursos compartidos, ya que, a menos que un agente reserve un EUTXO particular para sí mismo de alguna manera acordada, están disponibles para todos los demás. El [[algoritmo]] de aplicación debe garantizar que cuando se construyan las transacciones, los agentes individuales no compitan por los EUTXO en el grupo. Las transacciones que quieren consumir un EUTXO en particular son independientes entre sí desde una perspectiva de validación. Sin embargo, la dependencia existe ya que varios agentes pueden querer consumir el mismo recurso (el mismo EUTXO) al mismo tiempo para construir una transacción. En otras palabras, los agentes quieren trabajar simultáneamente. Una solución que se utiliza actualmente son las '''transacciones masivas'''. Los agentes buscan los UTXOs de solicitud adecuados que deseen interactuar con un grupo de liquidez en particular para cumplir con el intercambio solicitado. Los agentes hacen eso teniendo en cuenta todas las demás solicitudes de intercambio disponibles e insertan los intercambios seleccionados en una transacción de lote grande. Al crear una transacción por lotes, los agentes saben qué los EUTXOs ya se han utilizado. Pueden garantizar que un EUTXO en particular no se use dos veces dentro de una transacción por lotes.<ref>Andrychowicz, M., Dziembowski, S., Malinowski, D., Mazurek, L.: Modeling bitcoin contracts by timed automata. In: International Conference on Formal Modeling and Analysis of Timed Systems. pp. 7–22. Springer (2014)</ref><ref>{{Cita web|url=https://iohk.io/en/research/library/papers/the-extended-utxo-model/|título=The Extended UTXO Model}}</ref><ref>{{Cita web|url=https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/|título=Cardano’s Extended UTXO accounting model – built to support multi-assets and smart contracts}}</ref><ref>{{Cita web|url=https://cardanians.io/en/understanding-cardano-extended-utxo-200|título=Understanding Cardano Extended-UTXO}}</ref><ref>{{Cita web|url=https://docs.cardano.org/learn/eutxo-explainer|título=Understanding the Extended UTXO model}}</ref>
(''[https://api.zotero.org/groups/478201/items/T24L95MI/file/view?key=Qcjdk4erSuUZ8jvAah59Asef Ver White paper del modelo EUTXO]'')
== Referencias ==
|
