Cardano ratifica la actualización del modelo de costos de Plutus y fija la aplicación para el 18 de junio

La gobernanza en cadena de Cardano ha ratificado la actualización del Mainnet Plutus Cost Model, con la aplicación programada para el 18 de junio de 2026. Se ha pedido a los desarrolladores y a los equipos de dApp que prueben los contratos inteligentes, los constructores de transacciones y la lógica de estimación de costos en Preview y Preprod antes de que se aplique el cambio.

By SongMarketCap

Cardano News - Cardano ratifica la actualización del modelo de costos de Plutus y fija la aplicación para el 18 de junio

Cardano ratificó la acción de gobernanza para la actualización del Mainnet Plutus Cost Model el 13 de junio de 2026. Según Intersect MBO, la aplicación está programada para el 18 de junio alrededor de las 21:45 UTC. El cambio de parámetros del protocolo actualiza los modelos de costos de Plutus para V1, V2 y V3, los conjuntos de parámetros utilizados para calcular las unidades de ejecución de las transacciones de contratos inteligentes en Cardano.

La gobernanza de Cardano aprobó la acción Update Plutus Cost Models

La acción de gobernanza, titulada “Update Plutus Cost Models”, se presentó como un cambio de parámetros del protocolo en la mainnet de Cardano. En CardanoScan, la acción figura como ratificada bajo el ID de acción de gobernanza gov_action1eqhnsdyf3exhp5mqt7sdjtl7xy69wqg8tvg854psns2jt72cra3qqrcnr8r.

CardanoScan muestra cinco votos del Comité Constitucional a favor, sin votos en contra y sin abstenciones. El voto de DRep figura con 3.94 mil millones de stake a favor, equivalente a un 68.61 por ciento de apoyo. Los SPOs no eran elegibles para votar en este tipo de acción de actualización de parámetros, lo cual también se muestra en los datos del explorador.

La ratificación significa que la acción de gobernanza recibió la aprobación requerida a través del proceso de gobernanza en cadena de Cardano. La aplicación es el paso separado en el que el cambio de parámetros aprobado se aplica a la red. Después de la aplicación, los modelos de costos actualizados pasan a formar parte de los parámetros de mainnet usados por las herramientas que estiman presupuestos de ejecución, comisiones y el comportamiento de los scripts de Plutus.

Los modelos de costos de Plutus V1, V2 y V3 reciben nuevos valores en cadena

El Plutus Cost Model determina la parte de la comisión de una transacción que corresponde a la ejecución de scripts de Plutus. Asigna unidades de ejecución mediante componentes de CPU y memoria, que luego se utilizan para calcular comisiones de las transacciones que usan contratos inteligentes.

Plutus V1 se refiere a la versión original del entorno de scripting de contratos inteligentes de Cardano introducida con la era Alonzo. Plutus V2 amplió las capacidades de scripting con la actualización Vasil, incluidas funciones que habilitaron diseños de dApps más eficientes. Plutus V3 es una iteración más reciente asociada con la era Conway y actualizaciones posteriores, con un conjunto ampliado de funciones integradas y parámetros del modelo de costos.

La acción de gobernanza en cadena actualiza los arreglos completos del modelo de costos para plutusV1, plutusV2 y plutusV3. Los materiales anunciados destacaron cambios relacionados con equalsByteString en V1, V2 y V3, así como las operaciones con enteros divideInteger, modInteger, quotientInteger y remainderInteger en V3. Una aclaración técnica pública en el hilo de Intersect también indicó que los cambios no se limitan a valores de CPU y que hay cambios adicionales en V1 y V2, incluidos costos de memoria.

Para los desarrolladores, la fuente autorizada es el conjunto completo de nuevos valores registrados en la acción de gobernanza en cadena y mostrados a través de CardanoScan, Cexplorer, AdaStat y herramientas relacionadas. No se publicó en el anuncio una tabla oficial que compare todos los valores anteriores y nuevos, por lo que los equipos que necesiten una comparación técnica completa deben contrastar los nuevos arreglos en cadena con las definiciones del modelo de costos del ledger que estaban activas previamente.

Los desarrolladores deben volver a probar ExUnits, comisiones y presupuestos de scripts

Intersect pidió a los desarrolladores y a los equipos de dApp que prueben sus configuraciones en Preview y Preprod antes de la aplicación. El recordatorio se aplica a los protocolos DeFi, la infraestructura NFT, las integraciones de monederos, los indexadores, los constructores de transacciones y los servicios de backend que calculan comisiones, CPU, memoria y valores de colateral antes de enviar transacciones a mainnet.

La prueba práctica para los equipos consiste en volver a ejecutar y volver a estimar los costos de los scripts utilizando el código actual de las dApps, los constructores de transacciones y las bibliotecas de estimación de costos. El objetivo es confirmar que los scripts siguen ejecutándose dentro de los límites de ExUnits esperados y que los cálculos de comisiones y colateral se mantienen alineados con los nuevos parámetros del modelo de costos de mainnet.

Si un monedero, dApp o constructor de transacciones utiliza valores del modelo de costos codificados de forma rígida u obsoletos, puede calcular un presupuesto de ejecución incorrecto. Después de la aplicación, eso puede conducir a fallos en la ejecución de transacciones si el presupuesto es demasiado bajo, o a estimaciones de comisiones innecesariamente altas si la herramienta calcula a partir de supuestos antiguos o inexactos.

La actualización del Plutus Cost Model es una acción de cambio de parámetros del protocolo independiente, distinta del proceso de gobernanza del hard fork Van Rossem. Forma parte del mismo período de preparación técnica para Protocol Version 11, mientras monederos, proveedores de infraestructura, dApps y operadores de nodos se preparan para cambios en el ledger y en Plutus. El 18 de junio, los modelos de costos actualizados para parámetros existentes se aplican a mainnet, mientras que las primitivas de Plutus recién introducidas se activan solo después de la activación del hard fork.