perf(linear-vesting): optimize validator with raw BI.* data extraction

[Unisay]

Context

• What: Optimize the LinearVesting validator by replacing high-level Haskell pattern matching with raw BI.* data extraction
• Why: Reduce on-chain execution cost for the benchmark validator, demonstrating the performance gains achievable through manual data extraction
• Issue: IntersectMBO/plutus-private#2113

Approach

Replaced the entire validation logic in LinearVesting.Validator with hand-written BI.* operations that bypass the high-level PlutusLedgerApi pattern matching infrastructure. Instead of deserializing ScriptContext, TxInfo, and related types into Haskell ADTs, the optimized code works directly with BuiltinData using BI.unsafeDataAsConstr, BI.head, and BI.tail to extract fields positionally.

Uses standard Haskell multi-way if guards for control flow rather than the builtinIf lambda/unit pattern, based on experiments in PRs #7583 and #7584 which confirmed guards produce slightly better results (~5% CPU / ~7% MEM improvement).

The VestingDatum and VestingRedeemer type definitions and TH splices are preserved unchanged to maintain compatibility with Test.hs, which constructs test data using the typed API.

Changes

Validator optimization

• Replaced fromBuiltinData-based ScriptContext parsing with direct BI.unsafeDataAsConstr field extraction in untypedValidator
• Replaced txSignedBy with txSignedBy' using BI.caseList' over raw signatory list
• Replaced List.find with findInputByOutRef and findOutputByAddress using BI.caseList'
• Replaced assetClassValueOf with valueOf that walks the BI.unsafeDataAsMap structure directly
• Replaced getLowerInclusiveTimeRange pattern match with lowerInclusiveTime that reads constructor tags positionally
• Added getScriptHashFromAddress, getPubKeyHashFromAddress, getSpendingInfo helpers for raw credential extraction (no tag checks — ledger invariants guarantee correct credential types)
• Used BI.caseInteger for redeemer dispatch instead of fromBuiltinData-based VestingRedeemer parsing

Imports cleanup

• Removed PlutusTx.Prelude, PlutusLedgerApi.Data.V3 (full), PlutusLedgerApi.V3.Data.Contexts, PlutusTx.Data.List
• Added targeted imports: PlutusTx.Bool, PlutusTx.Builtins.Internal, PlutusTx.Trace
• Added explicit module export list

Golden files

• Updated .golden.eval, .golden.pir, .golden.uplc to reflect optimized output

Results

Metric	Before	After	Reduction
CPU	30,405,131	11,040,647	64%
MEM	128,919	45,828	64%
AST Size	1,854	1,467	21%
Flat Size	2,490	2,326	7%

[github-actions]

Execution Budget Golden Diff

318c729 (master) vs fc4db8b

output

plutus-benchmark/linear-vesting/test/9.6/main.golden.eval

Metric	Old	New	Δ%
CPU	30_405_131	11_040_647	-63.69%
Memory	128_919	45_828	-64.45%
Flat Size	2_490	2_191	-12.01%

This comment will get updated when changes are made.

[colll78]

This doesn't need the constructor tag check, it doesn't impact the security invariants of the contract as we require the public key hash to be present in txInfoSignatories which guarantees that it is indeed a valid public key hash (the ledger enforces this).

This can be rewritten (more efficiently) as:

BI.unsafeDataAsB $ BI.head $ BI.snd $ BI.unsafeDataAsConstr $ BI.head (BI.snd (BI.unsafeDataAsConstr addr))

Same with the other similar functions (ie. getScriptHashFromAddress). Even more-so for getScriptHashFromAddress because the ledger invariants already guarantee that the argument that we call this on inputAddress must be an address where the first field has the encoding Constr 1 [scriptHash] because inputAddress is the address of the input being validated by this script execution, which guarantees that it is indeed a script input and thus that the payment credential has constructor index 1 (is a ScriptCredential).

This is a micro-optimization probably so feel free to ignore it.

This check would be necessary if this contract had a minting policy for authentication tokens for creating vesting positions (in which case we would impose this check amongst other checks to enforce that the beneficiary address is indeed a valid public key address with the correct constructor index and a single bytestring field that has the length of 28) AND the validator allowed anyone to claim the vested amount provided they send an output with that amount to the beneficiary address. This would be required because in such a scenario, if the constructor index of the beneficiary address was incorrect then the check that txOutAddressAsData satisfyingOutput == beneficiaryAddress would be unsatisfiable if beneficiaryAddress was not strictly enforced to have canonical builtin data encoding that matches the ledger (ie. if it had constructor tag 3, it would be unsatisfiable because there is no way to construct a tx such that the output in the script context has an address with constructor tag 3).

[Unisay]

Good call: applied in fc4db8b. Both getScriptHashFromAddress and getPubKeyHashFromAddress now skip the tag check entirely, since as you pointed out the ledger guarantees the correct credential type in both cases. Shaved off another ~360K CPU.

[zliu41]

Please add this to the validation benchmark. We need more better-optimized scripts in the validation benchmark.