Bump dependencies to GHC 9.6 and the latest plutus-tx/plutus-tx-plugin

[jstolarek]

In #35 we received the following feedback regarding our Plutus code:

The biggest performance gain will come from using a newer version of plutus-tx and plutus-tx-plugin. You are on 1.0.0.0 which was published in Oct 2022, and a ton of performance improvements have been made since then. If you are able to bump GHC to 9.6, I'd strongly recommend doing so, as that will allow you to use the latest version of plutus-tx-plugin, which supports GHC 9.6 only.

We need to bump those dependencies, i.e. move to GHC 9.6 and the latest version of plutus-tx. As of the moment of this writing the latest version is 1.12.0.0. This probably has to be done in two steps:

1. Bump dependencies in Nix, such that all the project dependencies compile. This needs to be done by someone who is familiar with Nix.
2. Fix all compilation errors in our project, since not all code is necessarily compatible with GHC 9.6. This needs to be done by devs familiar with Plutus.

See also input-output-hk/trustless-sidechain#65, which this ticket in fact duplicates.

---

IOG Jira: https://input-output.atlassian.net/browse/ETCM-6654

[kayvank]

I'll start working on this.
My suggestions is":
1- try to solve the issue is outlined above.
2- once the issue is resolved, consider updating the flake to follow iogx framework

[tgunnoe]

I would suggest using https://github.com/hercules-ci/flake-parts in place of iogx unless there's something specific here that iogx would allow for.

[kayvank]

@jstolarek
I am proceeding with step 1 above. I'd like to 1st simplify the cabal.project by removing source-repository-package where possible and rely on CHaP

[kayvank]

I would suggest using https://github.com/hercules-ci/flake-parts in place of iogx unless there's something specific here that iogx would allow for.

Thank you @tgunnoe , I am not familiar with the link you provided, but will take a look.
I like iogx for it has excellent documentation and support. Our devop team has been a supper star helping us in past projects to implement iogx. Additionally several of our projects have already adapted iogx,
Thoser were my primary reason

[jstolarek]

@kayvank unfortunately, I can't provide any meaningful feedback in this discussion. I am not familiar with Nix in the slightest, so can't really say which way of organizing Nix code is better.

[kayvank]

thanks @jstolarek, it is not an issue at this time as I think the first order of business should be upgrading to ghc9.x
Upgrading the nix framework could be addressed on a different ticket

[kayvank]

@jstolarek nix and ghci for the entire stack has proven very difficult. The libraries and dependence are very old and has proven difficult to keep the dependency thread among them clean. The difficulty is compounded by the fact that the nix flake has inputs to our vendor relate code, cardano-transaction-lib/plutip

At this stage, I'd like to propose to break this big problem into smaller ones:

1. create a nix develop for the onchain code with a newer ghc and plutus-tx-plugin as outlined in the ticket
2. once we have 1) working, we start to migrate the offchain code to the new environment

So in summary, I'd like to break this issue to two:

• migrate onchain project to ghc9.6 and the latest plutus-tx-plugin
• migrate offchain project

[jstolarek]

That sounds reasonable, but note that:

1. We have git hooks that format the code (make format-staged in repo root). This needs to work after the refactoring.
2. Currently, to export the scripts we run make update-scripts in the offchain (sic!) directory, which builds the on-chain code from there. This would have to be fixed so that scripts are updated from the on-chain directory and the resulting RawScripts.purs file is then moved to off-chain.

[tgunnoe]

I also think the onchain/offchain separate upgrade paths and dependency tracking will help keep the bill of materials more legible, even if it increases the size of the lockfile in the meantime.

[jstolarek]

@kayvank A quick question regarding your second bullet point. Can you elaborate what you mean by migrating offchain project? Do you want to bring it up-to-date as its own separate project, which is potentially related to input-output-hk/trustless-sidechain#707? Or do you want to integrate everything back into one monolithic project?

[kayvank]

@jstolarek I chose my words poorly, as migrate is not the correct word to use here, my apologies.
My intentions is to do enough nix and flake changes to upgrade the onchain to the proper ghc 9.x per ticket so that we may use the recommended plutus-tx-plugin.
Once that is completed, start building the offchain code in this newly nix environment, and add runtime dependencies of the oncnain code as required.

I think tackling anything beyond the above points is out of scope for this ticket.

[kayvank]

made a request to release cardano-address to CHaP, this should simplify the cabal.project a bit and help with managing the offchain build dependencies + build cache
see slack conv: https://input-output-rnd.slack.com/archives/CG1FBSDMM/p1709107638018839

[jstolarek]

I think tackling anything beyond the above points is out of scope for this ticket.

I agree with this, and your proposed solution sounds good. (I should have more to say on this by the end of the day - please give me a few hours).

see slack conv: https://input-output-rnd.slack.com/archives/CG1FBSDMM/p1709107638018839

I'm afraid I don't have access here. Could you give a quick summary of what this is about?

[jstolarek]

Separating on-chain Nix bits from off-chain also lays groundwork for #710.