IntersectMBO / IntersectMBO/plutus
`compile` compiles for the wrong Plutus Core version
- Dominant language
- Haskell
- Stars
- 1.6k
- Forks
- 508
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 22
Description
### Summary
We're working on porting PlutusV1 contracts to PlutusV2; but when compiling these new contracts using the latest `main` branch, it produces scripts with the version prefix `010100`, which I assume is the new version with sum-of-products terms; it also means it produces UPLC with these unrecognized terms ("Unknown term constructor tag: 8.")
As far as we can tell, there's no way to opt-out of this new compiler to produce contracts that work on main net.
Is the recommendation still to use 1.3.0, or is there some other best practice that I'm missing?
### Steps to reproduce the behavior
1. Compile a simple minting script with the latest `main`
### Actual Result
2. Observe a script, such as: ```584e0101000033222222800245209b4e9e9af27b5dfa4d383be20535b94b16f4c0aa00ddc4b1ea4391396518bb500048811c000000000000000000000000000000000000000000000000000000000001```
3. Observe that the version is 010100
4. Observe that at byte 10, there is an "80"
5. When evaluating the script on mainnet (or with Lucid, for example), you'll receive this error:
```
error: Uncaught (in promise) "Redeemer (Mint, 0): Parse error: So far we parsed\n\n[ [ (lam i(lam i(lam i(lam i(lam i(lam iparse error)))))) not parsed] not parsed]\n\nand we ran into error: Unknown term constructor tag: 8.\n\nHere are the buffer bytes (5 preceding) [00, 33, 22, 22, 22, 80, 02, 45, 20, 9B]\n\nBuffer position is 7 and buffer length is 77"
```
### Expected Result
Plutus v1 and v2 scripts should compile succesfully for mainnet use; or there should be some way to specify the version of the VM / Compiler to use.
### Describe the approach you would take to fix this
_No response_
### System info
N/A
Contributor guide
Assessment
This issue has not been assessed yet.