Skip to content

Logbook 2025 H1

Jump to bottom
Sebastian Nagel edited this page Jan 9, 2025 · 1 revision

January 2025

2025-01-08

SN on aiken pinning & cleanup

  • When trying to align aiken version in our repository with what is generated into plutus.json, I encountered errors in hydra-tx tests even with the same aiken version as claimed.

  • Error: Expected the B constructor but got a different one

  • Seems to originate from plutus-core when it tries to run the builtin unBData on data that is not a B (bytestring)

  • The full error in hydra-tx tests actually includes what it tried to unBData: Caused by: unBData (Constr 0 [ Constr 0 [ List [ Constr 0 [ Constr 0 [ B #7db6c8edf4227f62e1233880981eb1d4d89c14c3c92b63b2e130ede21c128c61 , I 21 ] , Constr 0 [ Constr 0 [ Constr 0 [ B #b0e9c25d9abdfc5867b9c0879b66aa60abbc7722ed56f833a3e2ad94 ] , Constr 1 [] ] , Map [(B #, Map [(B #, I 231)])] , Constr 0 [] , Constr 1 [] ] ] , Constr 0 .... This looks a lot like a script context. Maybe something off with validator arguments?

  • How can I inspect the uplc of an aiken script?

  • It must be the "compile-time" parameter of the initial script, which expects the commit script hash. If we use that unapplied on the transaction, the script context trips the validator code.

  • How was the initialValidatorScript used on master such that these tests / usages pass?

  • Ahh .. someone applied the commit script parameter and stored the resulting script in the plutus.json! Most likely using aiken blueprint apply -v initial and then passing the aiken blueprint hash -v commit into that.

  • Realized that the plutus.json blueprint would have said that a script has parameters.

Clone this wiki locally