Cardano Updates

Signed-off-by: Chris Gianelloni <[email protected]>

Signed-off-by: Chris Gianelloni <[email protected]>

Signed-off-by: Chris Gianelloni <[email protected]>

Signed-off-by: Chris Gianelloni <[email protected]>

The plutus-tx-plugin (a GHC plugin) compiles Hydra's Haskell on-chain
scripts to Plutus IR; under GHC 9.12.4 it produces semantically equivalent
but byte-different bytecode than under GHC 9.6.7, leading to different
on-chain script hashes:

  vHead: 4e48afcd87e873c618ae00ee090d52e0451f3d25f1b7d3e397c30b3e
      -> 33c88da88a31e24fa98eeaf94751e9dc5c8d627384df4ba56ba49ab5

  mHead: 5c5cec68dcb9157324fb4030c764890830da6a335410419279a9723e
      -> a804ae87994b0771a78df1fb6c68ff0cc9af71786cc4424307e87f5e

The GoldenSpec module explicitly anticipates this scenario:

> This is also crucial in case we cannot reproduce them exactly as they
> were originally compiled using plutus-tx; which is not unlikely given
> we need to have the exact same version of plutus-tx, all its
> dependencies, and GHC.

Regenerated by deleting the .plutus files and running the golden test
under GHC 9.12.4. Note: anyone publishing scripts from this branch will
deploy them at the new hashes; existing on-chain deployments under the
old hashes remain usable by hydra-nodes pointing at them via
--hydra-scripts-tx-id.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Signed-off-by: Roland Kuhn <[email protected]>

Signed-off-by: Roland Kuhn <[email protected]>

Flake lock file updates:

• Updated input 'CHaP':
    'github:input-output-hk/cardano-haskell-packages/2d77199bbdf795a52169bbcf8eae88aee3794bad?narHash=sha256-6KW3OSVTA7yBvOEgFXmQrquSwN9wX3r5Hfk3mgnUfso%3D' (2026-05-13)
  → 'github:input-output-hk/cardano-haskell-packages/8479db771a3186eb326e42d8480eddc20a208275?narHash=sha256-BveisGfAV1GBrwP83S5w0D7B1t3VPaoHGGlRcnHYN5E%3D' (2026-05-22)
• Updated input 'emanote':
    'github:srid/emanote/64a8635e8fd69de932d27dc4c823c49ae0eac594?narHash=sha256-AkTPllEo7ZHzhD2lrtGimISCIGDkqNccznMiKDmluns%3D' (2026-05-15)
  → 'github:srid/emanote/6950760d46b656a015ee4e0ff0e6c2847b63889c?narHash=sha256-FQW0yOXoXLxfau2xVcaQA8J7Lo1ici9yxMAM0dHgqjg%3D' (2026-05-17)
• Updated input 'haskell-nix':
    'github:input-output-hk/haskell.nix/ecfcaa3151563f42565f5580307d4bbf99f0925c?narHash=sha256-aqMNjBtGXpO/ARrkihBJzldQQrW%2BLEKMqdt3Bbc7rfg%3D' (2026-05-17)
  → 'github:input-output-hk/haskell.nix/7d490982dc8b72cda8da55430bb3481feabe70c8?narHash=sha256-VKPTBz9gC7HPTNpIbcLwWDFqZ0V0mc/3CGSiUXY8aI4%3D' (2026-05-24)
• Updated input 'haskell-nix/hackage':
    'github:input-output-hk/hackage.nix/fc0a8974b156018427014b23f21a3a7e553714d4?narHash=sha256-Ak1ZTnsu33IKx1PQdalx9qBTpDrGtb1xeCRj2/%2Bveqo%3D' (2026-05-17)
  → 'github:input-output-hk/hackage.nix/97a118740edc9c012943d9e30ac6b3ab9abc1688?narHash=sha256-Zf%2B5mk56YwjsZrxhMchMC64KA8/Ei4POSGKrVIZBe7w%3D' (2026-05-24)
• Updated input 'haskell-nix/hackage-for-stackage':
    'github:input-output-hk/hackage.nix/318f304831f26ba2d9f8c0f9dcc914aff1878710?narHash=sha256-QJgROerh6vsyyTgHOSe8MBAgRaCDwKqkNQDZkGYmNeg%3D' (2026-05-17)
  → 'github:input-output-hk/hackage.nix/aec75c7642addf7fae7da9e8684aaee29a2fdb90?narHash=sha256-aU44iA1O9EdJ9b%2B6IQVItAac9FDnt/b73/F5scEvvn0%3D' (2026-05-24)
• Updated input 'haskell-nix/stackage':
    'github:input-output-hk/stackage.nix/ffee50f3d3732a3bcbfd0364105c10de0b28c711?narHash=sha256-hOaeX9sb8OToTbKVlLHzErIcHq28eD3RTtZIrPosWdU%3D' (2026-05-17)
  → 'github:input-output-hk/stackage.nix/61e1deec80661083f2eb2988dab95686a2385ca4?narHash=sha256-nKNdYwQY3rELiNg2s1fbOmLBS3w1KEEFlmyaqWThVr4%3D' (2026-05-24)
• Updated input 'nixpkgs':
    'github:NixOS/nixpkgs/65e451e0d2f4b9f3baa27566cd27cc430a4303ec?narHash=sha256-znYfvMw9Mh3f0c384cOUgqhjrb/vaTCXrcg9q6KtSkI%3D' (2026-05-17)
  → 'github:NixOS/nixpkgs/6dce29a1d5bafbe5f8aaff0aa5e9dc2b65ca73a8?narHash=sha256-%2Bu86fh3e4Rv568V3HlM7ho3nfdgjtVqrM3H6ZCCwRKk%3D' (2026-05-24)

Update Discord link and add IntelliJ integration

chore: downgrade `blockfrost-tests` to make the CI green

CI failure on the previous push exposed two issues with my initial pin to
.87:

1. **Smoke test "libsodium not initialized"**: pinning Mesh to `.87` pulled
   in different `@cardano-sdk/*` transitive versions than preprod's known-
   good lockfile, and the resulting libsodium-wrappers-sumo / libsodium-sumo
   combination fails WASM init under Node 20 in CI. Preprod runs Mesh
   `.102` for `core/core-csl/core-cst`, `.100` for `provider`, `-40` for
   `react`, and its smoke test passes — so pin to those exact versions.

2. **Pin alone doesn't fix the user**: with `.102` we're back on the same
   CBOR-encoding Mesh that broke their wallet's signature in the first
   place. The verify guard added in the previous commit converts that into
   a friendly error, but the user still can't vote.

   Extended `mergeSignerWitnesses`: when the wallet returns a full signed
   Transaction (not just a witness set), and its body bytes differ from
   ours, and we have no pre-existing witnesses to invalidate, *use the
   wallet's body*. The wallet's vkey signature was made over its body, so
   adopting it makes the signature verify and lets the submit succeed.
   This handles the first-signer case — which is the typical case for
   "I clicked Approve & Sign and it failed" — without changing behaviour
   for multi-signer flows where prior witnesses would be invalidated.

Also dropped the libsodium override commit's package.json entry — it's not
needed once we match preprod's exact Mesh versions, and trying to pin
`libsodium-sumo` to 0.7.10 broke Node 22's WASM loader.

Added unit test covering the body-swap recovery path; existing 3 tests
still pass (4 total).

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The 0.7.16 release ships `dist/modules-sumo-esm/libsodium-wrappers.mjs` with
a relative `import "./libsodium-sumo.mjs"` whose target file isn't in the
package — the actual sumo binary lives in the separate `libsodium-sumo`
package and is wired up via package.json `exports`. Node's strict ESM
resolver (used by `tsx` in the CI smoke runner, and by Next.js at build
time) doesn't follow the cross-package indirection and throws
`ERR_MODULE_NOT_FOUND` before any Mesh helper has a chance to run.

Preprod's pre-existing lockfile pinned 0.7.10, which works. Regenerating the
lockfile to land the Mesh pin pulled 0.7.16 (the latest in the ^0.7.5 range
the cardano-sdk transitively allows), breaking both `multisig-v1-smoke` and
the Vercel build. Override to 0.7.10 forces all `@cardano-sdk/crypto`
copies onto the working version.

Verified: `node --input-type=module -e "import('@meshsdk/core')"` now
succeeds (failed before the override). Unit tests still pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Adds an alternative component builder that runs `cabal v2-build`
inside a slice derivation and emits a cabal-store layout rather
than going through Setup.hs, alongside the existing Setup-based
v1 builder.  Selected per-project via the new `builderVersion`
option (default `1` for now; flip to `2` to opt in on a
per-project basis).

What the v2 builder provides:

* Per-component cabal-store slices that compose into a single
  `~/.cabal/store/ghc-<version>/` layout via `composeStore`.  Each
  slice's UnitId matches what a downstream `cabal v2-build` would
  compute against the real compiler, so a v2 store can be reused
  by interactive cabal invocations without recomputation.
* Public sublibrary support (`library <n>` stanzas) end-to-end —
  not currently supported by v1's Setup-based path.
* A v2 dev shell (`shell-for-v2.nix`) wired through `project.shellFor`
  whenever `builderVersion = 2`.  Two exposure modes:
  `cabal-store` (default) pre-populates `~/.cabal/store` so plain
  `cabal v2-build` reuses the slice's units; `ghc-pkg` mode wraps
  `ghc` / `ghc-pkg` with `GHC_ENVIRONMENT` / `GHC_PACKAGE_PATH` so
  `ghc -e` and similar see the composed store directly.
* A shared ghc shim (`ghc-shim.nix`) used by both the slice's
  `cabal v2-build` and the v2 shell so the user-facing compiler
  matches the slice compiler.  Adds cabal near-compiler aliases,
  patches the ghcjs `ar command` setting (drops missing `.o`s for
  backpack-on-ghcjs), and adds native-musl `unlit` /
  `ghc-iserv[-dyn|-prof]` aliases.

Plumbing changes:

* `builder/default.nix` + `builder/hspkg-builder.nix` dispatch on
  `builderVersion`.  v2-specific helpers (`buildCabalStoreSlice`,
  `composeStore`, `makeGhcShim`, the patched `v2CabalInstall`)
  live in `builder/default.nix`.
* `modules/project-common.nix` adds `builderVersion`.
  `modules/component-driver.nix` propagates it (plus
  `crossTemplateHaskellSupport` and `cabalProjectLocal`) into the
  pkg-set config.  `modules/stack-project.nix` forces v1 for
  stack projects (stack-to-nix doesn't produce the plan-json
  shapes v2 consumes).
* `modules/package-options.nix` adds round-trip options
  (`configureOptions`, `extraLibDirs`, `extraIncludeDirs`,
  `programOptions`) that v2 emits back into each slice's
  cabal.project.
* `modules/install-plan/configure-args.nix` extracts those
  round-trip options from plan.json's configure-args, and
  filters `-hide-all-packages` for v2 (cabal injects it on every
  Setup configure call; round-tripping it would fork UnitId
  hashes between plan-nix and slice cabal).
* `modules/install-plan/non-reinstallable.nix` skips the
  ghcjs/wasm boot-package hiding on v2 (v2 follows cabal's plan
  literally rather than overlaying haskell.nix's exclusions).
* `modules/shell.nix` adds the `exposePackagesVia` option.
* `lib/check.nix` adds a v2-slice branch that runs the installed
  exe under the platform's testWrapper, mirroring the v1 check
  semantics for slice derivations.
* `overlays/haskell.nix` propagates `builderVersion` /
  `cabalProjectLocal` through `addProjectAndPackageAttrs`,
  dispatches `shellFor` on `builderVersion`, and rebuilds
  iserv-proxy as both a non-profiled and profiled variant — v2
  reads the prof variant from `package iserv-proxy profiling:
  True` in cabal.project rather than `enableProfiling = true` on
  the .override (which v2 doesn't honour).
* `overlays/linux-cross.nix` + `overlays/mingw_w64.nix` add a
  `wrapGhc` derivation that bakes `-fexternal-interpreter -pgmi
  <iserv-wrapper>` into ghc itself — v2 can't put those into
  per-package `ghc-options:` (UnitId divergence), so it wraps the
  compiler instead.  The `compilerSelection` chain picks the
  wrapped ghc on cross targets.

Internal projects pin v1:

* `compiler/ghc/default.nix` (hadrian) and
  `overlays/bootstrap.nix` (hscolour) set `builderVersion = 1`
  explicitly so v2 evolution doesn't churn GHC builds while v2 is
  still settling.  `overlays/tools.nix` defaults
  `haskell-nix.tool` invocations to v1 for the same reason.

Tests are NOT migrated in this commit — the existing tests run
under v1 (the default) and exercise master's behaviour as before.
A follow-up will migrate or duplicate them under v2 once we know
which expectations need adjusting.

A user submitting a "Ballot Vote" on a 2-of-3 DRep multisig hit
`ConwayUtxowFailure (InvalidWitnessesUTXOW [VKey ce7cbe8f...])`. Decoding the
failing tx with this repo's CSL showed the witness's vkey hashes to a *valid*
script signer, but its Ed25519 signature does not verify against the tx body
hash. The body itself is byte-stable across CSL round-trips, so the wallet
must have signed a different (re-canonicalised) body.

Cause: package.json had `^1.9.0-beta.87` on @meshsdk/core/core-csl/core-cst/
provider/react; the lockfile had drifted to 1.9.0-beta.102. Some patch in
those 15 betas changed how Mesh emits CBOR (likely voting_procedures), so
app-built bodies no longer match what the wallet's encoder produces — the
wallet's signature verifies against its body but not ours.

Fix:
- Pin Mesh deps to exact .87 (.86 for provider) — no more silent patch drift.
- `mergeSignerWitnesses` returns `{ txHex, invalidVkeyPubKeysHex }`,
  verifying each newly-merged vkey's signature against the merged tx body
  hash. Witnesses already on the tx are not re-verified.
- transaction-card.signTx() and useTransaction.newTransaction() abort with a
  destructive toast (and skip submission + persistence) when the wallet
  returns a witness that doesn't verify. Offending pubkey is logged for
  debugging. The wallet user gets an actionable message instead of a chain
  rejection.
- jest.config.mjs: one-line moduleNameMapper for libsodium-wrappers-sumo's
  broken relative `./libsodium-sumo.mjs` import (pre-existing CI gap).
- .gitattributes: mark package-lock.json as linguist-generated so diff
  reviewers can skip the lockfile churn.

Test plan:
- New unit test `mergeSignerWitnesses.test.ts`: 3 cases (happy, mismatched
  body, pre-existing witness preserved) — all pass.
- `npx tsc --noEmit` on touched files: clean.
- Manual: decoded the user-shared failing txCbor; confirmed
  `blake2b-224(vkey) == 'f6ed79ef...'` (valid signer) but
  `pk.verify(body, sig)` is false. The new guard catches exactly this case
  before submit.
- Pre-existing test failures on preprod (proxyCiPreflight, proxyDRepInfo,
  signTransaction mock missing isBotJwt, pendingTransactions, apiSecurity)
  are in files unrelated to this fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>