Vasil hard-fork (HFC)

[dorin100]

• check successful era migration - after era migration (from Alonzo to Vasil):

• blocks are still created by stake pools
• rewards are still paid
• all the existing scripts are passing (in the Vasil era) (Shelley/Mary/Alonzo/Vasil transactions) - blocks, rewards, pool operation, etc

• query protocol parameters CLI command return correct values (protocol version included)
• transaction view output works for Vasil transactions and it contains all the new parameters when using Plutus v2

• reference inputs, collateral return, collateral total, more data in the transaction outs (inline datums, reference scripts, other scenarios)

• all the previous functionalities are working in the Vasil era
• after the HF, the correct protocol version is advised in the block headers (affected by this issue)
• upgrade nightly pipelines with the Vasil era scripts
• check consistency of the previews era related to the functionalities from the next era ([BUG] - Inconsistent handling of Babbage-only features in older Tx eras cardano-node#4424)

• Script size - it should be smaller compared with Alonzo
• Interpreter - it should be faster compared with Alonzo
• Tx Cost - the cost for interacting with Plutus scripts should be smaller than in Alonzo (it should be cheaper to reference a script than to submit it)

• Mainnet approach --> Update proposal to add PlutusV2 cost model on top of PlutusV1 cost model #1158

• cost model V2

  • the next epoch after the HF, the cost model will need to be updated in order for Plutus V2 to take effect
  • the cost of the transactions without Plutus scripts should not be impacted by the second cost model --> Vasil hard-fork (HFC) #996 (comment)
  • we can change any of the cost models with an update-proposal (make and confirm changes to different parameters of both cost-model_V1 and cost-model_V2, for parameters having the same name and also different names)
    • we’re using a positional translation, so the Plutus cost parameter names should be in the same relative positions, but they don’t need to be the same names

• there is full backward compatibility between Plutus v1 and Plutus v2

LE:

• leaderlogs - compare the results in the epoch before and after the hard-fork -> [BUG] - leaderlog error with hardfork transition epoch cardano-node#4478

[vfrsilva]

@dorin100 can you please add a point to test/review cost model for Plutus V1 and Plutus V2 after the Plutus V2 cost model is voted (1 epoch after HF)

[dorin100]

@dorin100 can you please add a point to test/review cost model for Plutus V1 and Plutus V2 after the Plutus V2 cost model is voted (1 epoch after HF)

Done. This new point generated some new open questions; check the main thread.

[dorin100]

some details about the cost models:

There are four pricing parameters

• fixed tx cost
• cost per tx byte
• cost per CPU unit
• cost per mem unit

The first two apply to simple txs, all apply to Plutus
There are then two cost models that drive the last two parameters

• Plutus v1
• Plutus v2

These only apply to Plutus scripts

---

1. what cost model will be used for simple transactions (not involving Plutus scripts)?

• fixed cost + n x per byte cost

2. would we have the possibility to make specific changes to any of the cost models with update proposals?

• yes, we can change any of the cost models with an update-proposal

3. should the same fields from the 2 cost models be in the same positions/have the same names?

• we’re using a positional translation, so the Plutus cost parameter names should be in the same relative positions, but they don’t need to be the same names - this is a bit ugly but was the easiest solution

[dorin100]

useful (CIP-0047? | Hardfork safety mechanism) - cardano-foundation/CIPs#318